2018 年 7 月 12 日 ， 我 正在 美国 波 特 兰 出 差 ， 很 荣幸 收 到 张 军 的 邀请 ， 为 他 们 团队 最 新 撰写 的 书写 序 。 与 OpenStack 相 关 的 书籍 在 国内 已 经 有 很 多 了 ， 而 且 OpenStack 在 国内 的 发 展 也 进入 了 一 个 成 熟 
期 ， 但 是 特别 讲 OpenStack CIMCD 或 者 定制 化 CIMCD 系 统 的 书籍 ， 市 场 上 鲜 有 耳闻 。 恰 着 此 时 ，7 月 14 日 ， 美 国 商务 部 正式 发 布 公告 ， 宣 布 解除 对 中 兴 的 拒绝 令 。 中 兴 通 讯 也 在 官方 微 博 上 发 布 一 条 振奋 人 
心 的 信息 : “满怀 信心 再 出 发 ! ”。 相 信 此 刻 中 兴 和 上 万 员工 的 心情 是 激动 的 ， 我 们 所 有 人 心情 也 是 激动 的 。 反 思 这 件 事 情 ， 我 们 的 教训 是 深刻 的 ， 没 有 技术 的 自主 创新 和 自主 可 控 ， 就 意味 着 将 来 可 能 
被 别人 牵 着 鼻子 的 着 脖子 。 因 此， 在 我 们 专注 的 软件 领域 ， 我 们 要 坚定 不 移 地 积极 地 投入 开源 事业 。 

言 归 正 传 ， 认 识 张 军 是 通过 OPNFV (Open Platform Network Function Virtualization) 社区 ， 他 是 中 兴 通 讯 在 OPNFV 技 术 指 导 委员 会 的 代表 ， 在 我 的 印象 中 ， 他 是 一 个 十 分 严谨 的 人 。 当 他 把 本 书 
草稿 的 电子 版 发 给 我 后 ， 我 粗略 地 看 了 一 遍 。 这 本 书 是 他 和 他 的 团队 对 Openstack CI/CD 系 统 各 个 组 件 开发 和 研究 多 年 的 成 果 ， 也 是 团队 多 年 实践 和 经 验 的 总 结 。 除 了 OpenStack 系 统 ， 现 在 很 多 软件 发 行 
版 比如 Linux、Android、OPNFV， 甚 至 是 边缘 计算 项 目 StarlingX 都 可 以 充分 利用 CIMCD 系 统 。 正 如 他 在 书 中 所 提 到 的 ，Openstack CI 的 框架 目前 只 用 于 OpenStack 社 区 基础 设施 的 管理 ， 了 解 前 台 的 
Openstack 的 人 很 多 ， 但 是 由 于 CIMCD 是 在 后 台 的， 接触 和 了 解 后 面 CMCD 的 开发 者 却 很 少 。 所 以 ， 对 于 一 个 要 全 面 掌握 系统 的 开发 人 员 来 说 ， 了 解 和 熟悉 CIMCD 也 是 十 分 必要 的 。 而 且 ，CIMCD 的 适用 范 
围 很 广 ， 定 制 化 非常 高 ， 熟 悉 了 OpenStack CIMCD， 则 一 通 而 百 通 。 


书 中 除了 介绍 OpenStack CI/CD 中 的 关键 技术 和 组 件 之 外 ， 还 有 一 大 特色 是 分 享 了 中 兴 团 队 在 社区 Cl/CD 工 具 集 上 的 实践 经 验 ， 同 时 指导 读者 如 何 定制 化 和 修改 OpenStack CIMCD 系 统 ， 包 括 剪 裁 和 扩 
展 ， 即 告诉 读者 如 何以 一 通 百 。 这 一 点 是 非常 有 益 的 ， 因 为 针对 不 同 内 部 使 用 需求 ， 针 对 不 同 项 目 需求 ， 是 不 能 直接 将 OpenStack CIMCD 拿 来 使 用 的 ， 在 这 点 上 我 深 有 体会 。 举 个 例子 ， 我 现在 在 英特尔 公 
司 从 事 边缘 计算 和 StarlingX 发 行 版 的 开发 工作 ， 第 一 个 艰巨 任务 就 是 要 编译 和 管理 StarlingX 的 众多 依赖 包 ， 并 快速 搭建 起 StarlingX 的 CI/CD 体 系 。 目 前 这 项 任务 由 以 前 负责 Linux 开 发 的 墨西哥 团队 执行 ， 
同时 该 任务 也 是 该 边缘 计算 其 他 所 有 功能 开发 的 前 提 和 依赖 。 它 不 是 简单 OpenStack CI/CD 的 拷贝 ， 在 这 条 路 上 我 们 也 费 了 些 周折 。 如 果 墨 西 哥 团队 能 了 解 OpenStack CMCD， 并 掌握 CIMCD 的 定制 化 ， 以 
后 在 任何 项 目的 Cl/CD 搭 建 道路 上 就 可 以 少 走 很 多 弯路 ， 相 信 本 书 对 需要 根据 项 目 搭 建 并 定制 CI/CD 系 统 的 读者 有 很 大 的 帮助 。 


另外 ， 开 源 的 持续 集成 /部 署 平台 Zuul 项 目 最 初 是 为 Dpenstack CI 测试 开发 的 ， 后 来 被 许多 不 同 的 组 织 所 贡献 和 使 用 。 在 今年 5 月 份 的 OpenStack Vancouver Summit 上 ，OpenStack 基 金 会 宣布 Zuul 
项 目 发 布 第 3 版 ， 并 且 正 式 成 为 由 Openstack 基 金 会 托管 的 第 三 个 独立 项 目 。 这 一 点 也 足以 说 明 CIMCD 系 统 对 一 个 项 目的 重要 性 。 需 要 了 解 Zuul 项 目的 读者 ， 在 本 书 中 也 能 找到 相应 的 答案 。 


最 后 ， 感 谢 张 军 和 他 的 团队 为 OpenStack 社 区 ， 为 开源 软件 社区 贡献 了 这 样 一 本 好 书 ， 希 望 众多 OpenStack 的 开源 项 目的 开发 人 员 、 运 维 人 员 , 以 及 爱好 者 们 能 在 书 中 找到 它 的 价值 ， 并 获得 帮助 。 


王 庆 博士 ， 英 特 尔 开源 技术 中 心 网 络 和 存储 开发 经 理 ，OpenStack 基 金 会 个 人 独立 董事 


读 了 董 文 娟 等 同事 创作 的 这 本 书 ， 我 感到 非常 高 兴 ， 并 由 囊 感 谢 创作 团队 的 杰出 贡献 ! 


云 计算 、 大 数据 、 人 工 智 能 是 21 世 纪 发 展 的 基石 和 助 推 器 ， 它 们 将 共同 促进 未 来 生产 力 的 提升 。 电 信 设 备 在 往 NFV、 云 原生 演进 的 过 程 中 越 来 越 多 地 使 用 和 借鉴 了 IT 思想 和 工具 链 。 这 些 新 技术 的 应 
用 ,加速 了 整个 产业 链 的 发 展 。5G 就 是 典型 的 综合 应 用 场景 ， 云 原生 、 微 服务 和 HTTP 接 口 规范 ， 莫 定 了 5G 攻 孝 发 展 的 基础 。 中 兴 通 讯 在 云 计算 领域 深耕 多 年 ， 致 力 于 利用 先进 的 技术 ， 研 发 更 快速 度 、 更 
大 容量 、 更 高 安全 、 更 具 弹 性 、 更 低 成 本 的 云 计算 基础 设施 。OpenStack 已 经 成 为 开源 云 计算 领域 的 事实 标准 ， 其 社区 拥有 一 套 完整 的 、 标 准 化 的 、 自 动 化 的 持续 集成 测试 平台 ， 它 不 仅 适 用 于 开源 社区 本 
身 ， 也 有 助 于 电信 产品 的 研发 。 本 书记 录 了 中 兴 通 讯 在 这 个 领域 的 探索 、 研 究 和 实践 ， 对 于 构建 自动 化 的 测试 系统 具有 很 好 的 借鉴 意义 ， 对 于 公司 数字 化 转型 起 到 了 基础 支撑 作用 。 


兴 通 讯 非 常 认同 和 重视 开源 社区 ， 且 致力 于 建立 开放 合作 的 生态 环境 。 公 司 加 入 了 全 球 多 个 开源 的 社区 ， 成 为 其 中 的 天 键 伙 伴 ， 比 如 Apache、CNCF、Openstack 和 OPNFV 等 。 中 兴 通 讯 在 NFV 领 
域 技术 的 发 展 ， 离 不 开 与 社区 的 合作 。 中 兴 通 讯 作 为 最 负 社 会 责任 的 高 科技 企业 之 一 ， 我 们 非常 愿意 将 我 们 的 知识 、 经 验 和 服务 分 享 到 社区 ， 回 馈 到 社会 。 


本 书 创作 团队 是 公司 在 开源 社区 合作 的 典范 ， 是 一 个 优秀 的 自 组 织 、 自 管理 、 自 激励 的 开放 合作 的 敏捷 团队 ， 他 们 内 通 外 联 与 社区 合作 ， 共 同 推动 NFV 和 开源 技术 的 发 展演 进 。 本 书 是 团队 在 
Openstack CIMCD 领 域 多 年 的 研究 和 实践 总 结 ， 很 乐意 将 这 本 优秀 的 著作 分 享 给 大 家 ! 


最 后 再 次 感谢 创作 团队 的 重大 贡献 ， 并 欢迎 各 位 读者 开启 精彩 的 阅读 之 旅 ! 


HR, PRANE RA R EK 


本 书 由 来 


过 去 十 年 ， 中 国电 信 业 快速 发 展 ， 语 音 和 数据 业务 需求 极 大 提升 ， 尤 其 当 以 安 卓 、iPhone 为 代表 的 智能 手机 推出 后 ， 数 据 业 务 的 增长 速度 远 超 预期 。 近 三 年 ， 移 动 数据 业务 每 年 以 大 约 90% 的 复合 增长 
率 增长 []， 这 对 设备 商 交 付 新 版 本 的 速度 提出 了 更 高 的 要 求 。 中 兴 通 讯 在 2013 年 就 启动 了 无 线 接 入 网 项 目 移植 虚拟 化 技术 预 研 ， 希 望 实现 软 硬 件 解 耦 以 缩短 版 本 交付 周期 ， 满 足 运营 商业 务 飞 速 发 展 的 需 
求 。 目 前 ， 这 些 虚 拟 化 研究 成 果 已 经 成 为 5G 的 基础 技术 标准 。 

虚拟 化 预 研 项 目 不 仅 涉及 电信 网 元 本 身 的 适 配 ， 还 涉及 开发 云 操作 系统 和 制定 操作 管理 规范 、 接 口 标准 。 而 云 操作 系统 是 虚拟 化 的 关键 技术 之 一 ， 综 合 考虑 云 操 作 系 统 开源 社区 影响 力 、 项 目 热 度 、 扩 
展 性 、 可 维护 性 、 业 界 认 可 度 等 因素 ， 项 目 团队 选择 OpenSstack 作 为 云 操作 系统 的 开源 解决 方案 。 但 电信 和 领域 常见 的 需求 ， 如 网 口 绑 定 、 高 速 转发 、 巨 页 (Huge Page) 、CPU 绑 核 等 功能 在 OpenStack 
社区 尚 不 支持 ， 如 何 把 虚拟 化 的 电信 网 元 (Virtual Network Function) 运行 在 OpenSstack 上 ， 并 提供 高 性 能 服务 ， 是 项 目 面临 的 巨大 挑战 。 在 此 背景 下 ， 笔 者 所 在 的 团队 开始 深入 参与 到 OpenStack 开 源 
社区 的 开发 工作 中 ， 推 动 社区 一 起 解决 这 些 关 键 技术 问题 。 

计算 、 存 储 和 网 络 是 OpenStack 虚 拟 层 三 大 基础 设施 服务 ， 其 中 存储 (Cinder) 项 目 涉及 厂商 的 硬件 集成 。Cinder 项 目 制定 了 一 套 Ap| 接 口 规范 ， 厂 商 的 存储 设备 若 需 要 集成 ， 需 向 社区 提交 遵守 该 接 
口 规范 的 驱动 程序 ， 并 搭建 一 套 C| 系 统 来 验证 ， 该 Cl 系统 需要 遵守 社区 第 三 方 CI 规范 [2 


图 0-1 是 一 个 简化 的 第 三 方 Cl 系统 架构 图 ， 厂 商 需 要 准备 的 有 : 


. 第 三 方 CI 系 统 ， 即 本 书 所 要 讲述 的 OpenStack CIA Zt; 该 系统 连接 厂商 的 存储 硬件 ， 并 与 社区 的 Gerrit 系 统 趾 连接 ， 监 控 stream-events 事 件 流 ; 当 社 区 Getrit 有 新 的 变更 和 补丁 提交 时 ， 将 变更 代码 与 厂 


商 提 供 的 硬件 环境 进行 集成 测试 并 向 社区 Gerrit 反 馈 测试 结果 ，; 
本 地 OpenStack 资 源 池 ， 为 第 三 方 CI 系统 运行 提供 虚拟 机 资源 ; 


“ 存储 设备 ， 用 于 对 变更 代码 进行 验证 。 
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图 0-1 第 三 方 CI 架 构图 


通过 这 种 机 制 ，Cinder 项 目 可 以 及 时 发 现 变更 代码 的 兼容 性 问题 ， 厂 商 也 能 及 时 发 现 变更 代码 对 设备 驱动 的 影响 。 所 有 第 三 方 CI 系统 的 执行 结果 都 会 显示 在 社区 Gerrit 系 统 每 个 代码 变更 的 评审 记录 
中 。 


OpenStack Cl 系统 提供 了 一 套 动态 调度 测试 任务 的 方法 ， 极 大 提升 了 开发 效率 ， 具 体 优点 如 下 : 

- 提高 CI 系统 的 并 发 性 ， 开 发 人 员 的 多 个 变更 测试 任务 不 需要 在 环境 排队 等 待 执行 ， 只 要 本 地 OpenStack 资 源 池 资 源 足 够 多 ， 就 可 以 并 行 执行 所 有 测试 任务 ， 这 可 以 显著 减少 开发 人 员 的 等 待 时 间 ; 
` 提高 测试 任务 的 可 管理 性 ， 使 用 YAML 文 件 描述 测试 任务 ， 易 阅读 、 评 审 ， 可 进行 版 本 管理 ， 容 易 在 不 同 团队 之 间 复 制 和 重用 ; 

. 可 定制 虚拟 机 基础 镜像 ， 如 支持 不 同 的 操作 系统 、 不 同 的 软件 栈 配置 ， 增 加 了 在 项 目 实际 使 用 中 的 适用 性 和 灵活 性 ; 

. 提高 测试 任务 的 准确 性 ， 每 次 测试 任务 都 在 相同 的 环境 和 配置 下 执行 ， 不 存在 静态 环境 中 测试 任务 执行 后 对 软件 、 配 置 文件 等 清理 不 完整 而 导致 测试 任务 执行 不 一 致 的 问题 ，; 

可 复 用 云 环 境 ， 统 一 运 维 资 源 ， 减 少 维护 开销 并 提高 资源 利用 率 。 


这 套 CI 系统 不 仅 适 用 于 Openstack 社 区 组 件 研 发 ， 也 适用 于 电信 网 元 的 开发 。 基 于 此 ， 笔 者 所 在 的 团队 潜心 研究 Dpenstack CIl 这 套 系 统 ， 结 合 自身 需求 ， 增 强 了 CD 的 方案 和 实践 ， 最 终 形成 一 套 完整 
的 CIMCD 解 决 方案 。 这 套 解决 方案 在 团队 得 到 广泛 应 用 ， 无 论 是 内 部 的 维护 工作 ， 还 是 对 外 的 技术 合作 ， 都 由 该 CIMCD 系 统 提供 技术 支撑 。 公 司 数 字 化 转型 战略 和 敏捷 实践 触发 了 内 部 项 目 对 CIMCD 技 术 的 重 
视 ， 越 来 越 多 的 团队 渴望 获得 和 提升 这 方面 的 技能 。 所 以 ， 笔 者 所 在 的 团队 作为 开源 技术 的 先锋 ， 在 给 内 部 进行 培训 和 技术 转移 的 过 程 中 ， 诞 生 了 把 对 该 系统 的 经 验 、 实 践 汇总 整理 并 出 版 成 书 的 想法 。 


了 解 OpenStack 的 人 很 多 ， 但 对 OpenStack Cl 系统 有 实际 应 用 经 验 的 人 很 少 ， 主 要 是 因为 OpenStack CI 系统 目前 只 用 于 OpenStack 社 区 基础 设施 的 管理 。 国 内 DevOps 思 想 和 技术 在 最 近 两 年 才 得 到 
大 规模 接受 和 实践 ， 大 家 对 了 解 CIMCD 相 关 技 术 的 需求 非常 高 。 笔 者 很 荣幸 把 这 套 适 用 性 广 、 定 制 性 强 和 并 发 性 高 的 CI 系统 介绍 给 大 家 ， 同 时 回馈 社区 ， 推 广 和 普及 这 些 基础 设施 技术 。 目 前 ， 国 内 外 几乎 
没有 该 套 系统 的 完整 描述 ， 因 其 组 件 众多 ， 且 搭建 该 系统 需要 投入 大 量 的 人 力 物力 (笔者 团队 搭建 该 系统 花费 了 近 两 个 月 的 时 间 ， 这 还 是 在 使 用 社区 已 有 安装 脚本 进行 最 简 安 装 的 情况 下 ) 。 从 目前 已 经 接 
入 的 第 三 方 CI 向 环境 来 看 ， 国 内 搭建 OpenStack Cl 系统 的 公司 凤毛麟角 ， 说 明 在 OpenSstack 技 术 如 此 普及 的 情况 下 ， 国 内 公司 对 这 套 OpenStack Cl 系统 仍然 知之 甚 少 。 希 望 本 书 能 让 读者 少 走 弯 路 ， 事 半 
zal, 


本 书 从 逻辑 上 可 分 为 四 部 分 : 
第 一 部 分 (第 1 章 和 第 2 章 ) 对 DevOps 的 发 展 、 文 化 和 转型 进行 了 简单 说 明 ， 并 引入 本 书 的 重点 内 容 OpenStack CI/CD 说 明 其 对 DevOps 转 型 的 重要 性 。 
. 第 二 部 分 (第 3~9 章 ) 以 系统 管理 员 视 角 对 OpenStack CI/CD 中 的 每 一 项 关键 技术 进行 详细 的 分 析 和 阐述 ， 这 些 关键 技术 包括 : 


* 版 本 控制 (Git) 与 代码 评审 (Gerrit) 系统 ， 开 源 社 区 最 常用 的 代码 管理 和 代码 评审 工具 ，Gettit 系 统 与 本 书 介绍 的 持续 集成 系统 和 门 控 系统 进行 密切 配合 ， 共 同 完成 整个 开发 流程 。 


. 持续 集成 系统 (Jenkins) ， 最 为 流行 的 一 款 开源 持续 集成 工具 ， 用 于 代替 人 工 进 行 重 复 的 持续 集成 工作 ， 同 时 也 为 促进 持续 交付 提供 技术 支撑 ; 该 章 还 介绍 了 JJB (Jenkins Job Builder) 工具 ， 通 过 


YAML 文件 来 定义 Jenkins 任 务 ， 提 升 Jenkins 任 务 的 开发 和 运 维 效率 。 


: 门 控 系 统 (Zuul) ， 确 保 主 线 稳 定 ， 仅 当 与 变更 相关 的 所 有 测试 都 通过 后 ， 才 会 将 变更 合 入 相应 的 目标 分 支 中 。 它 保障 了 测试 任务 获得 最 大 程度 的 并 行 ， 且 在 发 生 错误 的 情况 下 ， 自 动 回 滚 ; 它 支 持 
指定 项 目 间 变 更 依赖 关系 ， 解 决 跨 项 目 集 成 问题 ， 致 力 于 守护 项 目 及 关联 项 目 。 


. 资源 管理 系统 (Nodepool) ， 通 过 在 OpenStack 资 源 池 中 动态 创建 虚拟 机 并 作为 Jenkins Slave 节 点 添加 到 Jenkins 的 资源 池 中 ， 确 保 不 同 的 测试 之 间 互 不 影响 ; 在 测试 结束 后 ， 删 除 使 用 过 的 虚拟 机 ， 保 证 
对 每 个 测试 任务 都 能 提供 一 致 的 测试 环境 ; 此 外 ，Nodepool 还 集成 了 镜像 制作 功能 ， 支 持 测 试 环境 的 定制 开发 。 


“日志 服务 器 ， 对 所 有 测试 任务 提供 统一 的 日 志 存 储 服务 ， 以 便 回溯 测试 故障 。 

日志 分 析 系 统 ， 将 测试 过 程 中 的 测试 日 志 导 入 Elasticsearch 中 ,便于 出 现 问 题 时 ,快速 检查 和 分 析 故 障 。 

- 公共 组 件 ， 重 点 介绍 了 支持 OpenStack CI 系统 组 件 之 间 进 行 协作 和 通信 的 系统 ， 包 括 任务 分 发 《Gearman) 、 消 息 队 列 (ZetoMQ) 和 分 布 式 协调 服务 (ZooKeepet) 等 组 件 。 

. 第 三 部 分 (第 10 章 ) 描述 团队 在 社区 工具 和 经 验 的 基础 上 的 经 典 实 践 ， 以 及 如 何 进行 裁剪 、 扩 展 和 定制 化 修改 以 满足 团队 需求 。 

. 第 四 部 分 (第 11 章 ) 探讨 当前 解决 方案 中 存在 的 不 足 和 可 行 的 优化 方案 ， 并 描述 了 社区 当前 正在 经 历 的 变化 和 未 来 的 演进 路 线 。 

忌 管 本 书 各 章节 功能 相对 独立 ， 笔 者 建议 顺序 阅读 第 3 ~ 5 章 ， 因 为 这 些 章节 大 量 使 用 了 前 序章 节 的 基本 概念 和 术语 ;， 其 他 章节 可 以 根据 需要 进行 翻阅 。 
本 书 读者 

本 书面 向 基础 设施 管理 团队 、DevOps 团 队 或 致力 于 了 解 CMCD 的 技术 人 员 ， 可 作为 学 习 Openstack 社 区 CIMCD 基 础 设施 解决 方案 的 教材 ， 协 助 你 高 效 搭建 社区 第 三 方 CI 系统 。 
勘误 与 交流 


笔者 团队 在 编写 本 书 的 过 程 中 虽 已 经 进行 了 大 量 的 内 部 评审 和 检验 工作 ， 但 因 时 间 紧 、 精 力 有 限 ， 难 免 会 出 现 一 些 错 漏 ， 敬 请 广大 专家 和 读者 批评 、 指 正 。 你 可 以 把 与 本 书 相关 的 意见 或 建议 发 送 到 电 


子 邮箱 openzero@aliyun.com 中 。 
本 书 中 团队 实践 和 示例 代码 都 可 以 在 GitHublel 上 进行 下 载 ， 读 者 可 以 尝试 使 用 并 与 我 们 进行 探讨 。 


致谢 


本 书 的 创作 团队 是 一 支 拥有 丰富 专业 技术 经 验 的 团队 ， 团 队 成 员 有 十 年 以 上 电信 领域 的 工作 经 验 、 四 年 以 上 开源 社区 技术 研究 和 贡献 经 验 。 本 书 是 团队 智慧 和 多 年 经 验 的 结晶 。 使 用 本 书 介绍 的 技术 和 
经 验 ， 和 希望 可 以 帮助 你 的 团队 高 效 管理 公司 内 部 的 基础 设施 ， 节 省 大 量 人 力 资源 ， 并 提供 快速 而 稳定 的 服务 。 

本 书 由 创作 团队 在 业余 时 间 编 写 ， 占 用 了 团队 成 员 很 多 家 庭 生 活 的 时 间 ， 每 位 成 员 都 付出 了 极 大 的 努力 并 克服 了 诸多 困难 ， 对 此 表示 感谢 。 感 谢 所 有 团队 成 员 不 大 其 烦 ， 一 次 又 一 次 地 评审 修订 ， 以 认 
真 严 谨 的 态度 验证 了 本 书 所 有 的 代码 实践 。 感 谢 董 文 娟 在 本 书 编写 过 程 中 有 力 地 组 织 、 协 调和 推进 ， 没 有 你 辛勤 的 付出 ， 本 书 不 可 能 顺利 完成 。 


在 此 ， 还 要 感谢 我 的 领导 潘 峰 、 王 前 和 施 嵘 ， 没 有 你 们 的 信任 和 支持 ， 不 可 能 有 本 书 的 诞生 。 感 谢 中 兴学 院 的 间 林 院 长 对 本 书 的 指导 和 建议 。 感 谢 Openstack 基 础 设施 团队 设计 出 如 此 优秀 的 工具 和 系 
统 ， 感 谢 你 们 在 日 常 工 作 中 及 时 答疑 解 惑 。 感 谢 机 械 工业 出 版 社 的 杨 福 川 和 李 艺 编辑 的 信任 和 支持 ， 及 时 更 正 了 本 书 中 较 多 的 排版 问题 。 


[1] http://www.chyxx.com/industry/201708/546504.html。 

[2] https:/ / docs.openstack.org/infra/system-config/third. party.html. 

[3] https:/ /review.openstack.org.« 

[4] https:/ / wiki.openstack.org/wiki/ThirdPartySystems o 

[5] 本 书 使 用 reStructuredText 语 言 编 写 ， 团 队 因 采用 该 工具 而 在 格式 排版 方面 节省 了 大 量 时 间 精 力 。 


[6] https://github.com/openzero 


第 1 章 DevOps 


什么 是 DevOps? 为 什么 DevOps 会 受到 越 来 越 多 的 关注 ? 


“DevOps” 是 英文 单词 “Development” 和 “Operation” 的 组 合 ， 即 开发 和 运 维 的 结合 。 目 前 DevOps 并 没有 权威 的 定义 ， 但 得 到 大 部 分 人 认可 的 是 ，DevOps 已 经 成 为 一 种 文化 价值 观 和 实践 方 
法 。DevOps 价 值 观 的 呈现 和 实践 并 不 依赖 于 特定 的 软件 ， 但 通过 合适 的 软件 工具 链 的 支撑 可 以 更 容易 实现 这 一 价值 观 。 


DevOps 使 得 业务 可 以 更 快 地 运营 ， 更 快 地 应 对 变化 。2017 年 DevOps 现 状 调查 报告 1 显示， 工作 于 DevOps 团 队 的 人 员 比 例 达 到 27%， 相 比 于 2014 年 ， 增 加 了 一 倍 。DevOps 能 够 缩短 上 市 时 间 ， 提 逢 
产品 质量 并 增加 营 收 ， 从 而 受到 越 来 越 多 的 公司 关注 并 进行 实践 。 


[1] https:/ /ask.qcloudimg.com/raw / yehe-133f028 /dorjc09 gaa.pdf。 


1.1 DevOpsiBjr 


谈 到 DevOps， 就 不 得 不 回顾 一 下 软件 开发 模型 (Software Development Model) [的 历史 。 软 件 开发 模型 是 指 软件 开发 全 部 的 过 程 、 活 动 和 任务 的 结构 框架 。 它 包括 需求 、 设 计 、 编 码 和 测试 等 阶 
段 ， 有 时 也 包括 维护 阶段 。 软 件 开发 模型 能 清晰 、 直 观 地 表达 软件 开发 全 过 程 ， 明 确 要 完成 的 主要 活动 和 任务 。 本 章 不 会 系统 介绍 曾经 出 现 的 所 有 软件 开发 模型 ， 只 选取 其 中 较 典 型 的 瀑布 模型 、 迭 代 模 
型 、 敏 捷 模 型 进行 说 明 ， 以 及 如 何 演进 到 DevOps。 


[1] https://baike.baidu.com/item/ 软件 开发 模型 。 


13.1. HFF RIRE 
瀑布 模型 严格 遵循 预先 计划 的 需求 分 析 、 设 计 “〈 可 细 分 为 系统 设计 、 概 要 设计 、 详 细 设计 ) 、 编 码 、 集 成 、 测 试 的 步骤 顺序 进行 。 上 一 阶段 的 成 果 输 出 成 为 下 一 阶段 的 工作 输入 ， 阶 段 之 间 通 过 交付 大 
量 的 文档 进行 传递 。 严 格 分 级 、 分 阶段 导致 团队 的 灵活 性 降低 ， 使 项 目 难 以 响应 需求 的 变化 ， 难 于 调整 或 调整 的 代价 极 高 . 


迭代 式 开发 模型 每 次 只 设计 和 实现 这 个 产品 的 一 部 分 ， 在 迭代 式 开 发 方法 中 ， 整 个 开发 工作 被 组 织 为 一 系列 短小 的 、 固 定 长 度 (如 4 周 ) 的 小 周期 ， 被 称 为 一 系列 的 迭代 。 每 一 次 迭代 中 都 会 包含 完整 的 
需求 分 析 、 设 计 、 编 码 与 测试 ， 再 通过 反馈 来 细 化 需求 ， 并 开始 新 一 轮 的 迭代 。 这 种 方式 弥补 了 瀑布 模型 中 的 一 些 弱点 ， 加 快 了 对 变更 的 响应 速度 ， 可 以 提前 识别 问题 ， 从 而 降低 了 项 目 风险 ,提升 了 项 目 
成 功率 和 人 生产率。 


敏捷 软件 开发 模型 ， 是 一 种 从 20 世 纪 90 年 代 开 始 逐 渐 引 起 广泛 关注 的 新 型 软件 开发 方法 ， 能 应 对 需求 的 快速 变化 。 敏 捷 强 调 开发 人 员 与 业务 专家 之 间 的 紧密 协作 ， 强 调 面 对 面 的 沟通 ， 强 调频 繁 交 付 新 
的 软件 版 本 ， 强 调 能 够 很 好 地 适应 需求 变化 的 代码 编写 和 团队 组 织 方法 ， 也 更 加 注重 软件 开发 中 人 的 作用 。 


瀑布 式 开发 ， 从 需求 到 测试 ， 要 求 每 一 个 开发 阶段 都 要 做 到 最 好 ， 特 别 是 前 期 阶段 ， 设 计 得 越 完美 ， 提 人 交 后 的 成 本 损失 就 越 少 ; 返 代 式 开 发 ， 不 要 求 每 一 个 阶段 尽善尽美 ， 而 是 先 实现 主要 功能 ， 再 通 
过 持续 反馈 逐步 完善 ; 敏捷 开发 ， 相 比 迭 代 式 开发 ， 两 者 都 强调 在 较 短 的 开发 周期 交付 软件 ， 但 敏捷 开发 的 周期 可 能 更 短 ， 更 强调 团队 的 高 度 协 作 ， 强 调适 应 性 而 非 预见 性 。 


1.1.2 ”DevOps 发 展 历史 
自从 人 类 创造 了 计算 机 ， 就 诞生 了 程序 员 (Programmer) 这 个 职业 ， 从 为 计算 机 编写 程序 以 利用 其 计算 能 力 ， 逐 渐 演 变 为 专职 的 实现 特定 功能 的 开发 人 员 (Developer) 。 后 来 由 于 存在 大 量 的 软 硬 
件 资源 需要 维护 ， 又 逐渐 出 现 专职 的 运 维 人 员 (Operator) 这 一 职业 。 


开发 人 员 关 注 更 快 实现 功能 并 交付 开发 产品 ， 运 维 人 员 关 注 如 何 使 产品 运行 得 更 加 稳定 。Dev 和 Ops 的 矛盾 主要 是 面向 适应 性 的 敏捷 软件 交付 和 面向 经 验 性 的 传统 运 维 之 间 的 矛盾 。 而 DevOps 打 破 了 开 
发 和 运 维 两 个 部 门 、 团 队 之 间 的 障碍 墙 。 


2009 年 6 上 月， 在 Velocity 大 会 上 ， 一 个 名 为 《10+Deploys Per Day: Dev and Ops Cooperation at Flickr》[1] 的 演讲 成 为 本 次 大 会 最 大 的 亮点 ， 几 乎 所 有 和 DevOps 相 关 的 资料 都 引用 该 演讲 作为 
DevOps 出 现 的 标志 事件 。 这 个 演讲 提出 : “以 业务 敏捷 为 中 心 ， 构 造 适应 快速 发 布 软件 的 工具 和 文化 。” 


第 一 届 DevOpsDays 于 2009 年 10 月 在 比利时 根 特 举 行 ， 这 次 聚会 开创 了 DevOps 活 动 的 先河 。 本 次 活动 尽管 只 通过 推 特 (Twitter) 发 起 和 召集 ， 却 出 乎 意料 的 成 功 。 世 界 各 地 的 开发 工程 师 、 运 维 工程 
师 ， 还 有 各 种 IT 管 理 人 员 、 工 具 爱 好 者 齐 聚 一 堂 分 享 相关 技术 和 实践 。 从 此 之 后 ，DevOps 在 全 球 开始 流行 起 来 。 近 几 年 随 着 微服 务 和 Docker 的 流行 ，DevOps 得 到 大 规模 的 应 用 和 实践 。 


敏捷 和 DevOps 并 不 是 孤立 或 对 立 的 关系 ， 其 实 敏捷 是 DevOps 中 的 关键 组 成 部 分 。 一 般 而 言 ， 敏 捷 关 注 于 开发 过 程 中 的 实践 ， 而 DevOps 包 含 从 开发 、 持 续 测试 、 持 续 部 署 到 运 维 的 整个 过 程 。 图 1-1 可 
以 更 好 地 帮助 我 们 理解 它们 在 软件 开发 过 程 中 所 处 的 环节 。 
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图 1-1 DevOps 生 命 周期 

. 敏捷 实践 包含 了 从 规划 (涉及 需求 分 析 和 设计 ) 到 代码 开发 和 构建 的 过 程 。 

- 持续 集成 CI (Continuous Integration). 在 敏捷 实践 的 基础 上 包含 了 持续 构建 和 测试 的 过 程 ; 持续 集成 加 强 了 对 开发 人 员 的 反馈 过 程 ， 快 速 验证 并 解决 问题 ， 提 升 开发 效率 。 

- 持续 交付 CD (Continuous Delivery). 在 持续 集成 的 基础 上 ， 增 加 了 持续 进行 版 本 交付 的 过 程 ; 持续 交付 加 强 了 对 测试 人 员 的 交互 过 程 ， 每 天 都 有 可 用 的 版 本 ， 避 免 测 试 阻塞 ， 提 升 测试 效率 。 


: DevOps 在 持续 交付 的 基础 上 ， 包 含 了 持续 部 署 和 运 维 反馈 的 过 程 ; DevOps 加 强 了 用 户 体验 ， 用 户 所 使 用 的 环境 每 天 和 迭代 更 新 ， 用 户 反馈 的 问题 短 时 间 得 到 更 新 ， 用 户 体验 得 到 持续 提升 。 


图 1-2 DevOps 循 环 


[1] https://cdn.oreillystatic.com/en/assets/1/event/29/10 + Deploys Per Day. Dev and Ops Cooperation at Flickr Pre- sentation.pdf。 


1.1.3 ”DevOps 循 环 


经 典 的 DevOps 循 环 如 图 1-2 所 示 。 


这 个 循环 包含 了 开发 和 运 维 两 部 分 工作 ， 通 过 自动 化 的 测试 和 部 署 把 这 两 方面 的 工作 进行 集成 。 一 份 关于 敏捷 和 自动 化 测试 的 报告 由 显示 70% 的 团队 采用 了 敏捷 实践 ， 但 只 有 30% 的 团队 采用 了 CI 实 
践 ， 至 于 CD 就 更 少 了 。 


[1] https:/ /sdtimes.com/agile/guest-view-agile-is-all-about-change-so-why-does-testing-remain-the-same o 


1.1.4 ”DevOps 价 值 


DevOps 可 以 缩短 软件 发 布 周 期 ， 提 升 软件 质量 、 安 全 以 及 反馈 速度 。 从 2016 至 2017 年 的 DevOps 现 状 调 查 变 化 中 可 以 看 到 ，2017 年 DevOps 进 一 步 提 升 的 目标 不 再 是 生产 效率 ， 而 是 质量 和 稳定 性 。 
DevOps 有 如 下 一 些 价值 [1]: 
文化 : DevOps 首 先是 一 种 团队 文化 的 转变 ， 团 队 拥 有 共同 的 目标 和 信仰 。 


` 沟通 协作 : 沟通 在 团队 工作 中 非常 重要 ， 团 队 可 以 通过 一 些 实时 工具 进行 协作 ， 通 过 持续 沟通 ， 团 队 的 任务 对 所 有 成 员 可 见 ， 团 队 成 员 掌 握 了 最 新 进展 ， 可 以 有 效 进行 技能 传递 ， 消 除 由 于 沟通 、 依 
赖 导致 的 无 效 等待 ， 改 进 团队 全 方面 的 能 力 ， 包 括 设计 、 开 发 和 监控 。 


| 信任 : 是 团队 的 最 大 特质 ， 没 有 对 团队 成 员 的 信任 ， 团 队 不 可 能 获得 成 功 ; 成 员 之 间 在 沟通 、 协 作 的 过 程 中 增强 了 相互 之 间 的 信任 ， 同 时 也 增强 了 团队 凝聚 力 ， 提 升 了 工作 质量 。 


` 减少 对 专家 的 依赖 : 此 前 大 部 分 组 织 都 是 领域 专家 领导 的 面向 功能 的 开发 团队 ， 比 如 开发 部 、 质 量 部 、 网 络 管理 部 、 数 据 库 管 理 部 等 。DevOps 通 过 取消 这 些 特性 团队 来 减少 对 专家 的 依赖 ; 团队 的 每 
个 成 员 都 是 通才 ， 可 以 解决 团队 面临 的 各 方面 的 问题 。 


` 系统 性 思考 : 以 业务 逻辑 的 视角 来 全 面 理解 系统 所 实现 的 功能 ， 而 不 只 是 局 限于 深入 理解 某 个 领域 。 

. 精益 生产 : 为 组 织 的 纪律 、 效 率 和 有 效 性 设置 标杆 ; 在 此 过 程 中 努力 做 到 消除 浪费 、 加 强 质量 、 延 迟 承诺 、 快 速 发 布 、 尊 重 个 人 和 全 局 优化 。 
自动 化 : 所 有 需要 重复 执行 的 工作 都 努力 做 到 自动 化 、 代 码 化 ， 经 验 可 复制 、 可 推广 。 

. 持续 改进 : 创建 一 个 持续 改进 的 文化 氛围 ， 无 论 是 困难 还 是 收获 都 进行 分 享 ， 努 力 打 造 学 习 型 团队 ， 最 终 得 以 持续 改善 日 常 工作 。 


[1] https://www.slideshare.net/arunmurughan/top-10-devops-valueso 


1.2 DevOps 与 团队 文化 


DevOps 团 队 在 内 部 共享 态度 、 价 值 、 目 标 和 实践 ， 而 这 些 团 队 通 常 具有 如 下 特质 : 
` 团队 每 个 成 员 都 有 极 大 的 自主 权 ， 可 以 选择 愿意 承担 的 工作 、 任 务 和 挑战 ;充分 授权 让 团队 成 员 拥 有 极 大 的 自信 ， 同 时 也 能 够 得 到 快速 锻炼 。 


- 团队 成 员 共 担 责任 ， 对 于 错误 或 失败 每 个 人 都 有 责任 ， 是 团队 整体 的 错误 ， 而 不 归 责 于 某 个 成 员 。 


: 团队 成 员 在 接受 不 同 任务 的 过 程 中 ， 可 以 更 全 面 地 了 解 团队 承担 的 职责 ， 对 于 团队 成 员 实现 的 功能 也 增加 了 认识 和 理解 ， 在 此 过 程 中 ， 进 一 步 锻炼 了 自己 的 能 力 ， 可 以 参与 各 种 角色 和 功能 开发 。 


: 团队 成 员 分 享 快 乐 和 痛苦 ， 一 同 解决 技术 问题 、 跨 越 障 碍 ， 收 获 成 功 和 喜悦 ， 并 共同 分 担 在 此 过 程 中 的 痛苦 和 磨炼 。 
` 团队 成 员 在 解决 困难 、 分 担 和 分 享 的 过 程 中 学 会 担当 ， 因 而 ， 每 个 成 员 都 会 积极 处 理 团队 需要 承担 的 事务 和 需要 解决 的 问题 ， 进 一 步 提 升 团 队 的 主动 性 和 自治 性 。 


如 果 认 为 使 用 自动 化 的 工具 把 开发 和 运 维 工作 结合 在 一 起 就 达到 了 DevOps， 或 者 某 个 特定 的 团队 来 实施 DevOps， 其 他 团队 保持 传统 的 开发 模式 ， 其 实 就 是 打 着 DevOps 旗 号 的 伪 实 践 ，DevOps 的 价 
值 和 文化 很 难 在 这 种 模式 下 表现 出 来 并 发 挥 作 用 。DevOps 是 一 种 文化 的 转变 ， 团 队 成 员 同 时 负责 了 开发 、 部 署 和 运 维 的 工作 。 在 开发 过 程 中 不 考虑 如 何 部 署 ， 不 考虑 如 何 运 维 ， 仍 然 是 割裂 的 团队 和 工作 
模式 。 

在 向 DevOps 团 队 转 型 的 过 程 中 ， 可 以 通过 表 1-1 中 的 指标 把 团队 分 为 三 个 等 级 


表 1-1 DevOps 团 队 转 型 过 程 中 的 分 级 指标 


指标 \ 团队 EE 中 效能 团队 低 效 能 团队 
aa fis, 1 次 /周一 1 次 / 周 1 次 /周一 1 次 /月 


TIT EIE 


Qui 
变更 前 置 时 间 指 的 是 从 代码 提交 到 代码 在 生产 环境 中 成 功 运行 之 间 的 时 间 ; 低 效能 团队 的 代码 部 署 频率 在 2016 年 至 2017 年 间 得 到 了 大 幅 提 升 ， 从 1 次 /月 一 1 次 /半年 提升 到 1 次 /周一 1 次 /月 。 


让 我 们 看 一 下 高 效能 团队 和 低 效能 团队 在 表现 上 的 差异 : 


: 高 效能 团队 部 署 变更 到 生产 环境 的 效率 比 低 效 能 团队 快 440 信 。 
: 高 效能 团队 部 署 故障 恢复 时 间 比 低 效能 团队 快 96 倍 。 

- 低 效 能 团队 部 署 变更 失败 率 比 高 效能 团队 高 5 倍 。 

- 高 效能 团队 人 工 参 与 的 时 间 相 当 于 低 效 能 团队 的 60% 一 70%。 


: 高 效能 团队 倾向 于 使 用 主干 分 支 ， 每 天 向 主干 分 支 合 入 ， 分 支 只 存在 若干 小 时 ， 而 低 效 能 团队 则 采用 长 时 间 的 特性 分 支 。 


: 高 效能 团队 更 倾向 于 使 用 松 耦 合 架 构 ， 无 论 是 团队 独立 开发 的 应 用 和 服务 ， 还 是 必须 与 其 他 团队 合作 开发 需要 交互 的 服务 。 


中 国 第 一 份 DevOps 年 度 调查 报告 [1 中指 出， 国内 50% 的 团队 的 DevOps 实 践 经 验 都 少 于 1 年 ， 同 时 随 着 团队 在 DevOps 上 的 经 验 积累 ， 自 动 化 方面 的 投入 增加 ， 变 更 失败 率 可 以 得 到 逐渐 降低 。 从 2017 
年 的 DevOps 现 状 调查 报告 中 可 以 看 到 ， 在 亚洲 ， 工 作 于 DevOps 团 队 的 比例 大 约 是 10%， 而 在 美洲 则 高 达 54%， 这 也 就 不 难 解释 国内 经 验 不 足 的 现状 了 。 


[1] http:/ /www.10tiao.com/html/46/201712/2651000197 /1.html. 


1.3 ”DevOps 工 具 链 


以 下 是 业界 在 DevOps 工 具 链 方面 的 经 典 实践 (1]， 在 使 用 时 可 以 参考 。 


本 节 只 简单 列举 一 些 主流 的 DevOps 工 具 (如 图 1-3 所 示 ) ， 在 本 书 的 后 续 章节 ， 会 对 部 分 工具 进行 详细 阐述 。 


puppet CHEF Q 


ANSIBLE 
| Beeren 
B SALTSTACK 


DEPLOY 


*ÁKPACME NW» 


(Bamboo Sensu 


p 
JS JUnit Nagios | splunk> 


图 1-3 DevOps F44 
(1) Git 


Git 是 一 个 自由 县 开源 的 分 布 式 版 本 控制 管理 系统 ， 功 能 丰富 、 性 能 出 众 ， 但 又 十 分 轻 量 ,可 扩展 性 非常 好 。 轻 量 “ 廉 价 ”的 分 支管 理 使 其 非常 适合 于 敏捷 开发 ， 能 及 时 响应 需求 和 变化 ， 开 发 人 员 可 以 
在 多 任务 之 间 轻 松 切换 . 


(2) JIRA 
JIRA 是 项 目 与 事务 跟踪 工具 ， 被 广泛 应 用 于 缺陷 跟踪 、 客 户 服务 、 需 求 收集 、 流 程 审批 、 任 务 跟踪 、 项 目 跟 踪 和 敏捷 管理 等 工作 领域 。JIRA 提 供 了 一 系列 敏捷 工具 ， 如 Scrum 和 Kanban.。 
(3) Maven 


Maven 是 一 个 项 目 管理 和 自动 构建 工具 。 它 强调 构建 过 程 中 的 两 个 重要 方面 : 如 何 构 建 和 描述 依赖 天 系 。 在 实际 使 用 中 还 可 以 通过 一 系列 的 插件 来 扩展 各 个 阶段 的 流程 。 由 于 Maven 包 含 许多 重用 性 很 
强 的 默认 规则 ， 往 往 几 行 代码 就 可 以 完成 一 个 项 目的 构建 。Maven 通 常用 来 管理 Java 项 目 ， 但 也 可 以 用 于 管理 C#、Ruby、Scala 等 其 他 项 目 。 


(4) JUnit 
JUnit 是 一 个 Java 语 言 的 单元 测试 框架 。 多 数 Java 开 发 环境 都 已 经 集成 了 JUnit 作 为 单元 测试 的 工具 。JUnit 是 一 套 框架 ， 使 用 比较 简单 ， 只 要 继承 TestCase 类 ， 就 可 以 用 JUnit 进 行 自动 测试 了 。 
(5) Jenkins 


Jenkins 是 基于 Java 开 发 的 一 款 开 源 的 持续 集成 工具 ， 用 于 代替 人 工 进 行 重复 的 持续 集成 工作 ， 同 时 也 为 促进 持续 交付 提供 技术 支撑 。 它 支持 各 种 版 本 控制 工具 ， 如 CVS、Git、ClearCase 等 ， 并 且 可 以 
与 多 种 构建 工具 进行 集成 ， 如 Ant、Maven， 甚 至 有 自 定义 的 Shell 脚 本 。Jenkins 是 开发 和 部 署 连接 的 纽带 ， 社 区 活跃 ， 有 大 量 的 插件 来 扩展 其 功能 ， 是 实现 自动 化 的 关键 。 


(6) Puppet 


Puppet 是 一 款 集中 配置 管理 工具 ， 使 用 自 定义 的 DSL 描 述 语言 ， 可 管理 配置 文件 、cron 任 务 、 软 件 包 、 系 统 服务 等 。Puppet 采 用 C/S 结 构 ， 每 个 客户 端 周 期 性 (默认 半 个 小 时 ) 地 向 服务 器 发 送 请 求 ， 
获得 其 最 新 的 配置 信息 ， 保 证 系统 和 该 配置 信息 同步 。 


(7) Ansible 


Ansible 是 一 款 新 出 现 的 自动 化 运 维 工 具 ， 基 于 Python 开发 ， 有 批量 配置 、 部 署 、 运 行 命令 、 编 排 复 杂 任 务 等 功能 。 与 其 他 自动 化 运 维 工 具 的 显著 不 同 在 于 它 只 需 使 用 9SH 服 务 (SSH 可 以 说 是 各 种 
Linux 服 务 器 的 基本 服务 ) ， 它 不 需要 在 被 管理 节点 上 安装 组 件 或 代理 。Ansible 本 身 提供 了 上 干 种 Module 可 供 使 用 。 


(8) Nagios 
Nagios 是 一 款 开 源 的 网 络 监视 工具 ， 能 有 效 监 控 Windows、Linux 和 UNIX 等 各 种 主机 、 交 换 机 、 路 由 器 等 网 络 设备 。 在 系统 或 服务 状态 异常 时 可 以 发 出 邮件 或 短信 报警 ， 第 一 时 间 通 知 运 维 人 员 。 


[1] https:/ /www.quora.com/What-are-the-best-tools-to-leatn-DevOps-How-to-start-Dev Ops» 


1.4 DevOps 转 型 


DevOps 涉 及 文化 、 技 术 、 工 具 等 一 系列 支撑 ， 业 界 在 这 方面 有 太 多 的 选择 ， 但 却 没有 明显 的 解决 路 径 ， 而 国内 这 方面 的 人 才 又 比较 匮乏 ， 在 任何 一 方面 的 技能 缺乏 或 没有 得 到 合适 指导 的 情况 下 ， 目 
前 正在 DevOps 转 型 过 程 中 的 团队 很 容易 失败 。 


有 些 服务 提供 商 ， 已 经 开始 咨询 如 何 进行 DevOps 转 型 ， 但 痛苦 的 是 ， 能 胜任 这 项 工作 、 有 经 验 的 顾问 太 少 。 许 多 公司 希望 寻求 一 个 适合 所 有 人 的 模式 或 方法 ， 这 往往 会 造成 更 多 的 问题 。 举 个 例子 ， 
某 些 公司 在 既 不 考虑 这 个 转变 是 否 创造 了 足够 的 业务 价值 ， 也 忽略 了 必要 的 、 充 分 的 文化 转变 的 情况 下 ， 就 去 构建 一 个 DevOps 平 台 。 


通信 、 有 线 、 娱 乐 和 媒体 公司 为 了 跟 得 上 市 场 需求 ， 就 需要 有 能 力 持续 发 布 新 产品 和 服务 。 与 此 同时 ， 随 着 互联 网 普及 、 开 源 模式 得 到 更 广泛 的 接受 ， 新 技术 的 推广 速度 越 来 越 快 。 但 在 短 时 间 内 实现 
新 业务 、 上 线 新 活动 仍然 不 是 一 件 轻松 的 事情 ， 这 需要 强大 的 IT 基础 设施 的 支持 。 在 IT 所 面临 的 挑战 中 [1]， 可 以 看 到 ， 识 别 出 哪 些 上 T 领 域 需要 进行 DevOps 转 型 是 非常 困难 的 。 如 图 1-4 所 示 ，|T 领 域 所 面临 
的 挑战 大 约 有 十 项 ， 例 如 : 掌握 开源 模型 和 生态 系统 、 合 作 伙 伴 管 理 、 不 充分 的 集成 策略 、 缺 乏 清晰 的 技术 架构 路 线 图 等 ， 其 中 有 16% 受 访 者 第 一 选择 都 是 识别 出 哪些 IT 领 域 需要 进行 DevOps 转 型 。 


IT 面临 的 挑战 


掌握 开源 模型 和 生态 系统 
合作 伙伴 管理 
定义 不 完善 的 内 部 流程 (比如 ， 开 发 方法 论 ) 
不 充分 的 集成 策略 
需要 发 布 敏捷 / 非 线性 方法 (如 : DevOps) 的 文化 改变 
缺乏 对 多 供应 商 环境 的 管理 
缺少 合适 的 技术 专家 
缺乏 清晰 的 技术 架构 路 线 图 
没有 能 力 对 传统 IT 设备 进行 替换 /现代 化 
没有 能 力 识 别 哪些 IT 领域 应 当 转 换 到 DevOps 方 法 
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图 1-4 IT 所 面临 的 挑战 


本 书 将 协助 你 了 解 支撑 DevOps 的 技术 全 貌 ， 了 解 当前 你 的 团队 所 处 的 状态 ， 并 一 步 一 步 掌握 转 型 至 DevOps 团 队 所 需要 的 关键 技术 和 技能 。 通 过 本 书 的 学 习 和 本 书 作 者 所 在 团队 杀 历 的 最 佳 实践 的 总 
结 ， 希 望 能 够 协助 你 ， 选 择 出 适合 的 技术 路 线 ， 构 建 一 种 可 扩展 的 、 高 可 靠 、 高 并 发 的 Cl/CD 支 撑 平 台 ， 降 低 技 术 债 包 裕 ， 逐 步 完 成 DevOps 转 型 。 


[1] https://www.amdocs.com/sites/default/files/2018-01/amdocs-value-of-devops-wp.pdfo 


15 ”本章 小 结 


本 章 简要 介绍 了 软件 开发 模型 以 及 DevOps 实 践 的 价值 和 转型 工作 ， 本 书 的 后 续 章 节 将 详细 说 明 如 何 构建 一 个 支撑 DevOps 转 型 的 CI/CD 平 台 。 


第 2 章 CI/CD 


DevOps 贯 穿 软 件 生命 周期 的 全 过 程 ， 而 CMCD 则 是 它 的 基础 和 技术 核心 ， 在 没有 自动 化 测试 、 持 续集 成 和 持续 部 署 的 支撑 下 ，DevOps 就 是 空中 楼 阁 。 


2.1 CI/CD 介 绍 


Cl 是 指 持续 集成 (Continuous Integration, CI) ， 狭 义 的 CD 指 持续 交付 (Continuous Delivery, CD) ， 广 义 的 CD 指 持续 部 署 (Continuous Deployment) 。 所 谓 的 持续 ， 就 是 说 每 完成 一 个 完整 
的 部 分 ， 就 向 下 个 环节 交付 ， 发 现 问题 可 以 马上 调整 ， 使 问题 不 会 放大 到 其 他 部 分 和 后 面 的 环节 。 集 成 是 指 个 人 研发 的 软件 部 分 向 整体 部 分 交付 ， 以 便 尽早 发 现 个 人 开发 部 分 的 问题 ;交付 是 指 研发 尽快 向 
质量 团队 或 者 用 户 交 付 ， 以 便 尽早 发 现 生 产 环境 中 存在 的 问题 ;部 署 是 代码 通过 测试 后 自动 部 署 到 生产 环境 。 


2.1.1 “持续 集成 
随 着 软件 项 目 复杂 度 的 增加 ， 对 软件 组 件 之 间 的 集成 和 协同 工作 提出 了 更 多 的 要 求 。 如 果 开 发 人 员 在 后 期 才 进行 集成 ， 发 现 和 解决 问题 的 代价 会 很 大 ， 很 有 可 能 导 臻 项 目 延 期 甚至 失败 。 因 此 要 “尽早 
集成 、 经 常 集成 ”， 在 项 目 早期 发 现 的 风险 和 质量 问题 更 容易 得 到 解决 ， 并 保证 了 开发 进度 ， 持 续集 成 就 诞生 在 这 样 的 背景 下 。 


寺 续 集成 指 的 是 频繁 地 将 代码 合 入 到 主干 分 支 ， 只 有 通过 自动 化 测试 和 验证 的 代码 才能 被 集成 ， 目 的 是 让 产品 在 可 以 快速 迭代 的 同时 还 能 保证 质量 。 简 单 来 说 就 是 ， 针 对 软件 系统 的 每 次 变更 ， 能 持续 
且 自 动 地 进行 验证 : 构建 、 测 试 。 根 据 测试 结果 ， 我 们 可 以 确定 新 代码 和 原 有 代码 能 否 正 确 地 集成 在 一 起 ， 并 确保 核心 功能 正常 执行 ， 不 受 影 响 。Martin Fowler 说 过 : “持续 集成 并 不 能 消除 Bug， 而 是 让 


它们 非常 容易 被 发 现 和 改正 。 " 


持续 集成 的 流程 如 图 2-1 所 示 。 
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图 2-1 持续 集成 的 流程 


开发 人 员 首 先 获 取 当 前 工作 代码 库 的 副本 。 随 着 其 他 开发 人 员 将 更 改 后 的 代码 提交 到 | 源 代码 库 ， 此 副本 逐渐 与 远 端 代码 库 不 同步 。 代 码 库 可 能 不 仅仅 被 更 改 ， 还 可 能 添加 新 库 ， 或 者 增加 其 他 引起 依赖 
或 者 冲突 的 模块 。 


代码 分 支 检 出 的 时 间 越 长 ， 当 开发 者 分 支 重 新 集成 到 主线 时 ， 集 成 站 突 和 失败 的 风险 就 越 大 。 当 开发 人 员 将 代码 提交 到 代码 库 时 ， 必 须 先 更 新 代码 ， 使 本 地 副本 和 代码 库 中 的 主线 分 支 同 步 。 代 码 库 包 
含 的 更 改 越 多 ， 开 发 人 员 在 提交 自己 的 变更 前 必须 执行 的 工作 越 多 。 


开发 人 员 的 代码 提交 到 | 源 代码 库 ， 即 触发 Cl 服务 器 开始 构建 和 测试 ， 并 把 测试 结果 反馈 给 开发 人 员 。 测 试 通过 ， 代 码 即 合并 到 代码 库 中 继续 下 一 轮 的 测试 ;测试 失败 ， 开 发 人 员 根 据 反 馈 结果 修改 后 重 


新 提交 。 

以 上 过 程 循环 重复 即 持续 集成 。 

寺 续 集成 一 般 由 代码 变更 触发 ， 遵 循 先进 先 出 的 原则 ， 人 否则 容易 引起 混乱 ， 很 难 定位 是 谁 的 代码 破坏 了 集成 ; 而 且 构 建 时 间 不 能 太 长 ， 否 则 构建 次 数 太 少 ， 大 部 分 变更 一 直 处 于 等 待 状态 。 
需要 补充 一 点 ， 在 代码 提交 之 前 ， 开 发 人 员 必 须 在 本 地 完成 单元 测试 ， 集 成 测试 通常 在 检测 到 新 提交 时 在 CI 服务 器 上 自动 运行 。 
持续 集成 的 好 处 就 在 于 : 

: 快速 发 现 错误 ， 变 更 容易 追踪 ， 节 省 了 项 目 生命 周期 间 的 时 间 和 人 金钱。 

. 避免 版 本 发 布 最 后 时 期 才 集 成 的 混乱 。 

- 测试 失败 或 出 现 bug 时 更 容易 恢复 。 

“ 保证 主干 分 支 的 可 用 。 

` 频繁 地 集成 推动 开发 人 员 设 计 模 块 化 、 不 太 复 杂 的 代码 。 


可 以 说 ， 持 续集 成 是 DevOps 的 重要 基础 环节 。 


2.1.2 持续 交付 


持续 交付 指 在 持续 集成 的 基础 上 ， 频 繁 地 将 集成 后 的 代码 交付 给 质量 团队 (QA) 或 者 用 户 ， 部 署 到 更 贴近 真实 运行 环境 的 类 生产 环境 中 以 供 测 试 评审 ， 通 过 就 进入 发 布 ， 生 产 阶段 。 它 旨 在 更 快 更 频繁 
地 构建 、 测 试 和 发 布 软件 ， 有 助 于 降低 交付 的 成 本 、 时 间 和 风险 。 直 接 和 可 重复 的 部 署 过 程 对 于 持续 交付 非常 重要 。 持 续 交 付 并 不 意味 着 每 个 变更 都 会 尽快 部 署 到 生产 环境 中 ， 它 意味 着 每 次 更 改 都 被 证 明 
可 以 随时 部 署 。 持 续 交付 的 目标 不 是 要 消炎 缺陷 ， 而 是 要 规范 开发 和 测试 的 流程 ， 从 根源 上 提高 产品 的 质量 。 开 发 人 员 需 要 了 解 任何 代码 提交 都 可 能 会 随时 发 布 给 客户 ， 这 一 点 很 重要 。 


寺 续 交 付 的 流程 如 图 2-2 所 示 。 
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图 2-2 ”持续 交付 的 流程 


由 图 2-2 可 以 看 到 ， 持 续 交 付 在 持续 集成 的 基础 上 多 了 手工 部 署 和 系统 测试 等 流程 。 
持续 交付 的 产品 一 般 有 : 
- 源 代码 交付 : 比如 Python/Shell 脚 本 ， 但 这 些 文件 不 是 标准 的 软件 包 ， 不 利于 集中 管理 和 运行 。 
. 软件 包 交 付 : 比如 通过 RPMBuildet 工 具 制 作 Linux 标 准 包 。 
< 镜像 交付 : 可 以 是 虚拟 机 镜像 也 可 以 是 Docket 镜 像 。 
持续 交付 的 优点 : 
“ 提高 了 产品 质量 ， 加 快 了 产品 上 市 时 间 。 
. 产品 更 符合 用 户 需求 ， 提 高 了 客户 满意 度 : 频繁 地 发 布 使 开发 团队 可 以 更 快 地 获得 用 户 反馈 ， 专 注 于 开发 对 客户 有 用 的 功能 ， 有 助 于 构建 正确 的 产品 。 
* 提高 了 生产 力 和 效率 。 
在 实施 持续 交付 的 过 程 中 ， 必 须 考 虑 将 基础 设施 的 维护 纳入 进来 ， 作 为 支持 产品 运行 的 一 部 分 。 传 统 的 基础 设施 运 维 管理 存在 以 下 几 个 问题 : 
.自动 化 缺乏 串联 : 虽然 有 一 定 的 自动 化 ， 但 不 能 做 到 无 人 值守 ， 需 要 执行 一 些 临 时 命令 。 由 于 环境 释放 和 重建 的 成 本 高 ， 因 而 倾向 于 不 释放 ， 导 致 资源 利用 率 低 。 
: 与 产品 团队 脱节 : 很 难 根据 需求 随时 动态 增加 环境 。 需 要 额外 的 文档 来 描述 环境 ， 可 能 更 新 不 及 时 。 
通过 基础 设施 代码 化 (Infrastructure as Code, laC) 可 以 解决 上 述 问题 ， 大 大 有 助 于 实现 持续 交付 ， 促 使 持续 交付 和 DevOps 的 成 熟 ， 是 DevOps 的 一 项 关键 实践 。 
1aC 有 四 项 关键 原则 : 
* 再 生性 : 环境 中 的 任何 元 素 可 以 轻松 复制 。 
. 一致 性 : 无 论 何 时 ， 创 建 的 环境 中 各 个 元 素 的 配置 是 完全 相同 的 。 
` 快速 反馈 : 能 够 频繁 、 容 易 地 进行 变更 ， 并 快速 验证 变更 是 否 正确 。 


CDU: 所 有 对 环境 的 变更 应 该 容易 理解 、 可 审计 、 可 回 退 、 受 版 本 控制 。 


寺 续 部 署 是 持续 交付 的 下 一 阶段 ， 指 的 是 软件 通过 测试 后 自动 部 署 到 生产 环境 。 持 续 部 署 的 前 提 是 能 自动 化 完成 测试 、 构 建 、 交 付 等 步骤 ;目标 是 代码 在 任何 时 刻 都 是 可 部 署 的， 可 以 进入 生产 阶段 。 


寺 续 部 署 的 流程 如 图 2-3 所 示 。 


持续 部 署 意味 着 每 次 更 改 都 会 自动 部 署 到 生产 环境 中 ， 强 调 的 是 自动 化 。 为 了 进行 持续 部 署 ， 必 须 持续 交付 。 虽 然 持续 部 署 可 能 不 适合 每 个 团队 或 项 目 ， 但 持续 交付 是 DevOps 实 践 的 绝对 要 求 。 


2.1.4 CI/CD 工 作 流 


以 上 简单 介绍 了 CI/CD 的 概念 及 每 个 阶段 的 工作 流程 ， 整 合 起 来 即 一 套 完成 的 Cl/CD 流 水 线 。 在 实际 应 用 中 ， 一 般 通 过 代码 评审 系统 实现 代码 审查 和 集成 反馈 。 整 个 Cl/CD 系 统 配 置 了 代码 仓库 系统 、 代 
码 评审 系统 和 构建 工具 系统 。 
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图 2-3 ”持续 部 署 的 流程 
(1) 代码 提交 
开发 者 向 代码 评审 系统 (比如 Gerrit) 提交 代码 。 
(2) 测试 
系统 监听 到 代码 评审 系统 的 事件 后 即 触发 相关 的 测试 。 这 里 的 测试 有 如 下 几 种 : 
o 单元 测试 : 针对 函数 或 者 模块 的 测试 。 
. 代码 风格 检查 : 针对 代码 编写 的 风格 进行 检查 ， 比 如 Python 的 pep8 等 。 
| 集成 测试 : 功能 测试 。 
(3) 构建 
测试 通过 后 代码 就 可 以 合 入 主干 分 支 ， 同 步 到 代码 仓库 ， 进 行 下 一 阶段 的 构建 了 。 所 谓 构 建 ， 就 是 将 源 代码 转换 为 可 以 运行 的 软件 包 或 者 镜像 等 。 
(4) 测试 
构建 完成 后 进行 下 一 轮 测试 ， 此 阶段 的 测试 比 第 一 轮 测试 全 面 ， 包 括 功 能 测试 、 系 统 测试 、 性 能 测试 等 。 
(5) 交付 
第 二 轮 测试 通过 ， 代 码 就 进入 发 布 、 生 产 阶段 。 
(6) 部 署 
经 过 多 轮 测试 后 的 版 本 就 是 一 个 可 直接 部 署 到 生产 环境 的 稳定 版 本 ， 此 版 本 发 布 到 制品 库 上 ， 用 户 就 可 以 在 获取 版 本 后 通过 自动 化 工具 部 署 到 生产 环境 。 
工作 流 有 了 ， 接 下 来 就 是 选择 每 个 阶段 的 工具 搭建 整个 自动 化 的 生态 系统 ， 在 没有 制定 出 CIMCD 的 工作 流 时 考虑 工具 的 选择 只 是 纸上谈兵 ， 只 有 在 设计 好 工作 流程 和 业务 流程 之 后 再 选择 相 匹 配 的 工具 


集 才 有 意义 。 


2.2 OpenStack CI/CD 


OpenStack 作 为 现在 世界 上 第 二 大 开源 社区 ， 有 着 一 个 完整 的 、 标 准 化 的 、 自 动 化 的 持续 集成 测试 平台 。 它 由 社区 的 OpenStack-Infra 团 队 开发 维护 ， 具 有 高 可 靠 性 、 灵 活性 和 可 扩展 性 ， 对 于 搭建 企 
业内 部 CI/CD 系 统 有 非常 好 的 借鉴 意义 。 


Qu 


社区 的 持续 交付 ， 主 要 应 用 于 版 本 发 布 ， 后 文 如 不 做 特殊 说 明 ，CD 指 的 都 是 持续 交付 。 框 架 上 是 支持 持续 部 署 的 。 


2.2.1 当前 CMCD 系 统 的 形态 


以 Jenkins 作 为 持续 集成 工具 为 例 ，CMCD 系 统 的 复杂 程度 分 4 个 等 级 : 
第 1 级 : 如 图 2-4 所 示 ， 仪 使 用 Jenkins， 且 都 在 一 套 服务 器 上 ， 适 用 于 产品 项 目 较 小 、 资 源 较 少 的 场景 ， 使 用 维护 较为 简单 。 


第 2 级 : 如 图 2-5 所 示 ， 在 第 1 级 的 基础 上 引入 了 Gerrit 评 审 系 统 ， 但 是 具体 构建 还 是 在 本 地 ， 测 试 环 境 受 限 。 


«—».| local test 
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图 2-4 CI/CD 1 级 


«—> | local test 


图 2-5 CI/CD 2 级 


第 3 级 : 如 图 2-6 所 示 ， 也 是 目前 稍 具 规模 的 公司 或 社区 都 会 使 用 的 系统 ， 使 用 Jenkins+Jenkins-Job-Builder (JJB) 工具 。 在 执行 构建 时 ， 使 用 了 一 些 静态 资源 (如 虚 机 、 容 器 或 物理 机 ) ， 可 以 满足 
多 场景 构建 和 测试 需求 ， 但 是 资源 利用 率 较 低 ， 多 次 测试 的 环境 上 下 文 存 在 耦合 ， 目 前 OPNFV 社 区 使 用 这 种 框架 。 


第 4 级 : 如 图 2-7 所 示 ， 人 在 第 3 级 的 基础 上 引入 了 任务 门 控 系 统 (Zuul) 和 动态 资源 管理 系统 (Nodepool) 的 使 用 模式 ， 也 是 目前 Openstack 开 源 社区 的 应 用 。 


首先 我 们 来 学 习 一 下 OpenStack 社 区 的 Cl/CD 框 架 。 
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图 2-6 CI/CD 3 级 
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图 2-7 CI/CD 4 级 


2.2.2 OpenStack CI/CD 架 构 


首先 做 个 说 明 ， 社 区 的 CI/CD 已 经 演进 到 V3 版 本 ， 版 本 之 间 的 差异 比较 大 ， 本 文 所 有 框架 和 组 件 的 介绍 都 基于 V2 版 本 。 
CIMCD 系 统 框图 如 图 2-8 所 示 。 大 致 分 为 以 下 几 部 分 : 

Gettit 服 务 器 : 代码 评审 服务 。 

: CI Master: 主要 由 以 下 几 个 组 件 构成 。 

` 任务 门 控 系 统 (Zuul) 

. 持续 集成 系统 (Jenkins) 和 Jenkins 任 务 管理 工具 (JJB) 

.节点 资源 池 管 理 系 统 (Nodepool) 


- 集群 任务 分 发 系统 (Gearman) 


十 
dir 
Ni 
y 


这 一 部 分 是 系统 的 核心 ， 从 监听 代码 变更 ， 到 匹配 需要 运行 的 任务 ， 再 到 触发 任务 在 合适 的 
: CI Slave: 即 真 正 运行 测试 的 节点 ， 由 Nodepool 创 建 和 管理 ， 供 Jenkins Mastet 使 用 。 
: LogServer: 日 志 服 务 器 。 
ELKA EDMAR: 可 视 化 的 日 志 分 析 平 台 。 


* 制品 库 : 版 本 发 布 服务 器 。 
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图 2-8  CI/CDZR44 
下 面 先 简 单 介绍 各 组 件 功能 ， 后 续 章 节 会 对 每 个 组 件 做 详细 介绍 ， 包 括 工 具 原 理 和 使 用 方法 。 
(1) Gerrit 
代码 评审 管理 系统 ， 提 供 了 提交 和 补丁 管理 功能 ， 同 时 提供 了 丰富 的 用 户 权限 管理 ， 控 制 着 哪些 用 户 或 组 可 以 提交 代码 、 合 并 代码 、 管 理 代 码 库 并 提供 Gerrit 事 件 流 通知 服务 。 
(2) Zuul 


监听 Gerrit 事 件 流 ， 匹 配 到 对 应 的 pipeline， 以 及 该 项 目 在 这 个 pipeline 下 需要 执行 哪些 任务 。Zuul 可 以 处 理 具有 复杂 依赖 关系 的 多 个 补丁 (Patch) 。 它 能 监控 正在 执行 的 任务 ， 并 可 提前 结束 因 依赖 
的 Patch 测 试 失败 而 必定 失败 的 测试 任务 。 


(3) Jenkins&JJB 


Jenkins 负 责 具体 任务 的 构建 ， 每 个 Jenkins 任 务 都 需要 通过 配置 Jenkins 的 conf ig.xml 文 件 实现 。 而 在 任务 数量 达到 一 定 级 别 后 ， 手 工 去 配置 每 个 任务 会 变 得 非常 复杂 ， 而 且 手 工 配置 常常 会 带 来 人 为 操 
作风 险 。 


由 图 2-9 可 以 看 出 ， 手 工 干预 的 步 数 越 多 ， 部 署 成 功率 越 低 。 
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图 2-9 手工 操作 数 VS 部 署 成 功率 
XML 文件 也 不 易于 维护 ， 因此 引 | 入 了 JJB 这 个 工具 。 顾 名 思 义 ， 几 B 就 是 用 来 创建 Jen kins 任 务 的 工具 支持 Ya ml 或 者 son 格 式 存储 Jen s 任 务 模板 。 JJ B 通 过 解析 用 户 配置 的 文件 来 自动 生成 conf 
igxml， 支 持 模板 和 任务 组 的 方式 ， 复 用 性 高 


(4) Gearman 
在 Slave 节 点 增加 到 一 定数 量 后 (大 约 100 台 ) ，Jenkins 的 Master 节 点 就 会 出 现 问题 并 成 为 瓶颈 。 同 时 Master 节 点 是 单 点 部 署 ， 无 


法 完成 HA 等 处 理 。 为 了 扩展 Jenkins 而 引入 了 Gearman， 加 入 Gearman 后 ，Zuul 不 再 与 Jenkins 直 接 交 互 ， 而 是 提交 执行 任务 的 请 求 给 Gearman 服 务 器 ， 由 Gearman 服 务 器 完成 任务 的 分 发 。 通 过 


Gearman， 使 得 CI 测试 架构 具有 了 伸缩 性 : 通过 部 署 多 个 Jenkins Master， 实 现 了 Jenkins Master 的 HA 功能 。 


(5) Nodepool 


管理 和 维护 Jenkins slave 的 服务 ， 会 在 一 个 或 多 个 已 部 署 的 Openstack 环 境 中 自动 创建 Slave 节 点 ， 并 在 slave 节 点 运行 完 一 次 测试 后 删除 并 重建 。 


(6) LogServer 
日 志 服 务 器 ， 用 来 存储 任务 构建 的 所 有 日 志 信 息 。 如 果 测 试 失败 ， 开 发 者 可 以 查看 日 志 信 息 排查 故障 ， 同 时 它 也 是 ELK 采 集 日 志 的 源 。 


(7) ELK 
可 视 化 的 海量 日 志 分 析 平 台 ， 从 日 志 服务 器 上 采集 日 志 进 行 存储 、 分 析 及 可 视 化 ， 可 用 于 系统 监控 和 故障 排查 等 。 
(8) 制品 库 


存放 发 布 版 本 的 服务 器 。 


2.2.3 ”CI/CD 系 统 工作 流程 


CI/CD 系 统 的 框架 有 了 ， 如 何 搭建 并 配置 这 套 复杂 的 系统 使 各 组 件 之 间 协 作 是 本 书 要 详细 阐述 的 内 容 。 这 里 先 不 做 说 明 ， 后 续 章 节 会 详细 介绍 各 组 件 的 搭建 和 配置 ， 这 里 先 总 体 介绍 下 各 组 件 之 间 的 协 


作 流 程 。 
1. 准 备 工 作 
(1) Zuul 
: 配置 Zuul 对 接 的 Gerrit 服 务 器 。 
: 定义 pipeline 以 及 每 个 项 目 在 对 应 pipeline 下 运行 哪些 任务 。 
(2) JJB 定 义 项 目 任务 ,解析 任务 并 上 传 到 Jenkins 服 务 器 。 
(3) Nodepool 
一 个 可 用 的 OpenStack 云 环境 。 
“ 编译 镜像 ， 上 传 到 云 环境 。 


. 连接 到 云 环境 ， 用 上 传 的 镜像 退化 Slave 节 点 资源 池 。 


2. TER 

CI/CD 系 统 的 工作 流程 如 图 2-10 所 示 : 

1) 贡献 者 在 Gerrit 上 提交 新 Patch、 添 加 评论 等 。 

2) Gerrit 提 交 一 个 通知 事件 到 它 的 事件 流 中 (Event Stream) 。 

3) Zuul 从 Gerrit 的 事件 流 中 读 取 事件 ， 并 准备 好 本 地 项 目 代 码 ， 然 后 匹配 事件 到 一 个 或 多 个 pipeline， 并 找到 该 Patch 对 应 的 项 目下 的 pipeline 任 务 ， 把 任务 提交 给 Gearman 服 务 器 。 
4) Gearman 把 Job 分 发 到 可 以 执行 该 任务 的 Worker 上 。 

5) Worker 根 据 Slave 节 点 信息 在 对 应 节点 上 构建 任务 。 

6) 构建 后 操作 : 把 当前 任务 执行 的 日 志 信息 和 中 间 结 果 (包括 编译 结果 ) 拷贝 到 日 志 服 务 器 上 。 
7) 返回 任务 结果 到 Jenkins 的 事件 流 中 : 

. Jenkins 通 过 消息 方式 通知 Nodepool 此 次 任务 完成 。 

. Nodepool 删 除 执行 该 Job 的 Slave 节 点 ， 并 重新 团 化 新 的 节点 。 

.Jenkins 通 过 Geatman 把 当前 的 任务 执行 结果 返回 给 Zuul。 

8) 根据 测试 结果 ，Zuul 在 Gerrit 中 对 Patch 添 加 一 个 Review 结 果 。 

9) 贡献 者 在 Gerrit 上 可 以 查看 相关 日 志 信息 。 


如 果 当 前 变更 被 批准 合 入 主 分 支 ， 即 重复 第 (2) 步 进 入 持续 发 布 阶段 。 
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图 2-10 ”CI/CD 工 作 流 程 


2.3 本章 小 结 


本 章 主要 介绍 了 CI/CD 的 概念 及 OpenStack 社 区 的 Cl/CD 架 构 和 工作 流 ， 为 理解 其 工作 原理 ， 后 续 章节 将 详细 介绍 各 组 件 的 使 用 。 


第 3 章 ”版 本 控制 (Git) 与 代码 评审 (Gerrit) 


如 果 把 CI/CD 系 统 看 成 一 条 自动 化 的 流水 线 ， 那 么 代码 就 是 最 基础 的 原料 ， 提 交代 码 是 流水 线 的 第 一 道 工 序 。OpenStack 跟 大 多 数 软 件 项 目 一 样 ， 采 用 Git 作 为 版 本 控制 系统 进行 代码 管理 。 
作为 一 个 大 型 开源 项 目 ， 所 有 代码 的 合 入 都 需要 经 过 项 目 核 心 成 员 的 评审 。 在 OpenStack 的 基础 设施 里 承载 这 一 项 服务 的 系统 是 Gerrit。 经 过 评审 的 代码 才 会 被 推送 到 内 部 集成 的 Git 仓 库 中 。 
版 本 控制 和 代码 评审 分 别 从 技术 上 和 流程 上 增强 了 代码 的 可 追溯 性 ， 提 升 了 项 目 质 量 。 


本 章 将 介绍 Git 中 的 基本 概念 和 Gerrit 的 基础 配置 ， 特 别 是 其 中 与 Cl/CD 相 关 的 部 分 ， 以 便于 读者 深入 理解 整个 CI/CD 系 统 的 组 成 和 运行 机 制 |。 


3.1 ”版 本 控制 系统 (Git) 


Git 是 一 个 自由 上 且 开源 的 分 布 式 版 本 控制 管理 系统 。 它 的 适用 范围 非常 广泛 ， 从 简单 的 配置 文件 管理 到 大 型 的 软件 项 目 都 可 以 使 用 Git 来 进行 高 效 地 管理 。 


尽管 Git 的 功能 非常 丰富 ， 但 系统 本 身 十 分 轻 量 ,性 能 出 众 。 凭 借 低 成 本 的 本 地 分 支 、 灵 活 易 用 的 暂 存 区 以 及 多 样 化 的 工作 流 在 各 种 代码 管理 工具 如 Subversion、CVS、Perforce 以 及 ClearCase 等 之 中 
脱颖而出 。 


本 书 假设 读者 已 经 对 Git 有 基本 的 了 解 和 使 用 经 验 ， 仅 对 与 CI/CD 相 关 的 部 分 做 相应 的 介绍 。 


3.1.1 ”Git 仓库 (repository) 


Git 仓 库 在 CIMCD 系 统 里 的 位 置 如 图 3-1 所 示 。 


CI Build Server 


Fetch 


Authoritative 
Repository 


Fetch/Püsh Fetch/Push 


Developer 1 Developer 2 


图 3-1 ”Git 仓库 接 入 CI/CD 系 统 


通常 会 部 署 一 个 中 心 的 Git 仓 库 用 于 存储 代码 ， 里 面包 含 了 代码 的 历史 版 本 ， 以 及 各 个 分 支 所 指向 的 版 本 。 所 有 的 开发 者 都 向 这 个 仓库 提交 ， 集 成 测试 工具 也 从 这 个 仓库 获取 。 


3.1.2 Git (branch) 
几乎 所 有 的 版 本 控制 系统 都 支持 分 支 ， 以 方便 开发 者 独立 于 主线 之 外 工作 ， 达 到 一 定 完成 程度 之 后 再 合 入 。 有 一 些 代码 控制 系统 实现 分 支 的 方式 是 生成 一 份 拷贝 ， 在 大 型 项 目 中 这 是 一 个 相当 昂贵 的 操 
作 。 而 Git 中 的 分 支 本 质 上 就 是 对 某 个 历史 版 本 的 引用 ， 并 不 创建 其 他 对 象 ， 创 建 分 支 几 乎 可 以 瞬时 完成 。 


在 CMCD 系 统 中 ， 不 同 的 分 支 可 能 会 对 应 不 同 的 构建 任务 ， 或 者 不 同 的 环境 设置 。 对 于 集成 了 代码 评审 流程 的 系统 ， 未 经 评审 的 代码 通常 会 对 应 一 个 临时 分 支 。 对 于 评审 系统 ， 我 们 会 在 3.2 节 详细 介 


7J 
28. 


3.1.3 Git 提交 (commit) 
在 3.1.2 节 我 们 提 到 ，Git 分 支 是 对 某 个 历史 版 本 的 引用 ，Git 版 本 历史 不 是 记录 历次 变更 ， 而 是 一 系列 快照 ， 每 次 代码 提交 都 会 创建 当前 工作 区 的 一 个 快照 。 除 此 之 外 ，Git 提 交 中 还 包含 了 作者 姓名 和 电 
子 邮件 ， 输 入 的 信息 以 及 这 之 前 一 个 或 多 个 直接 相 邻 的 提交 。Git 为 每 个 提交 对 象 生 成 SHA-1 哈 希 ， 任 何 内 容 的 变更 都 会 导致 SHA-1 的 变化 。 


在 CMCD 系 统 中 ， 通 常会 把 被 构建 的 分 支 解析 为 对 应 提交 的 SHA-1 哈 希 。 因 为 SHA-1 冲 突 的 概率 低 到 可 以 忽略 的 程度 ， 所 以 只 要 确定 了 SHA-1， 就 可 以 追溯 到 唯一 的 构建 对 象 。 


3.1.4 ”Git 标签 (tag) 


代码 控制 系统 中 通常 使 用 标签 来 标记 一 些 重要 的 历史 版 本 。Git 支 持 两 种 类 型 的 标签 ， 轻 量 级 的 标签 和 带 注 记 的 标签 。 轻 量 级 的 标签 几乎 与 分 支 相同 ， 只 是 标签 不 会 被 轻易 移动 。 带 注 记 的 标签 则 包含 了 
更 多 的 信息 ， 诸 如 标签 创建 者 的 姓名 、 电 子 邮 件 和 日 期 以 及 输入 的 信息 ， 而 且 可 以 进行 数字 签名 和 校 验 。 在 标签 中 添加 注 记 是 比较 推荐 的 做 法 ， 这 样 可 以 提供 该 标签 的 背景 信息 ， 提 高 可 维护 性 。 如 果 你 只 
想 需要 一 个 临时 的 标签 或 由 于 某 种 原因 不 希望 保留 这 些 信息 ， 那 么 轻 量 级 的 标签 也 是 一 种 选择 。 


在 CMCD 系 统 中 ， 标 签 通常 用 于 标记 版 本 发 布 ， 同 时 也 可 能 触发 特定 的 构建 任务 ， 例 如 生成 二 进 制 发 行 包 ， 推 送 制品 库 等 。 


3.1.5 Git 引 用 (refs) 


上 面 几 个 概念 相互 之 间 的 关系 如 图 3-2 所 示 。 


HEAD 


' 


v1.0 master 


08ca9 — 34ac2 E F30ab 


Y Y 
snapshot A snapshot B snapshot C 


K3-2 ”Git 引用 


概括 起 来 说 : 

"Git 仓库 是 一 些 Git 提 交 (图 3-2 中 的 98ca9 等 ) 的 集合 。 

| 每 个 Git 提 交 都 对 应 了 代码 目录 的 一 个 快照 (图 中 的 Snapshot A 等 ) 。 

“Git 分 支 《 图 中 的 master) 是 对 Git 提 交 的 一 个 引用 ， 并 且 可 以 被 更 新 ， 以 指向 新 的 提交 。 

: Git 标 签 (图 中 的 v1.0) 也 是 对 Git 提 交 的 一 个 引用 ， 它 与 分 支 非常 类 似 ， 区 别 在 于 标签 被 设置 之 后 通常 不 会 再 被 移动 。 


这 里 我 们 反复 提 到 一 个 概念 ， 即 “引用 (reference, 或 缩写 为 refs) ”。 你 可 以 在 .git/refs 目 录 下 找到 对 应 的 文件 。 如 master 对 应 于 .git/refs/heads/master，v1.0 对 应 于 .git/refs/tags/v1.0。 这 些 文 
件 里 包含 了 相应 提交 的 SHA-1 值 ， 即 f30abhttp://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/17933/OEBPS/Text/...。Git 引 用 保存 了 Git 提 交 的 
SHA-1 值 ， 提 供 了 一 个 简单 的 名 字 来 作为 原始 SHA-1 值 的 替代 ， 更 方便 使 用 。 


细心 的 读者 可 能 还 注意 到 图 3-2 中 的 HEAD， 这 个 在 Git 中 表示 当前 提交 ， 与 分 支 、 标 签 不 同 ，HEAD 是 一 个 符号 引用 (symbolic reference) ， 它 的 内 容 不 是 原始 的 SHA-1 值 ， 而 是 指向 其 他 引用 。 例 
如 : 


$ cat .git/HEAD 
ref: refs/heads/master 


CI/CD 系 统 就 是 通过 上 述 各 种 不 同 的 引用 来 取得 特定 的 代码 版 本 进行 测试 ， 有 的 情况 下 还 会 生成 新 的 引用 (例如 创建 一 个 临时 引用 ， 把 代码 和 主 分 支 合并 ) 。 更 详细 的 内 容 会 在 第 5 章 进行 介绍 。 


3.2 ”代码 评审 工具 (Gerrit) 


Gerrit 是 一 个 基于 Web 的 代码 评审 工具 ， 其 内 部 采用 Git 作 为 版 本 控制 系统 。 


代码 评审 在 软件 开发 中 的 重要 性 无 须 袭 述 。Gerrit 的 目的 是 提供 一 个 轻 量 级 的 框架 ， 评 审 每 一 个 将 被 合 入 代码 库 的 提交 。 


是 交 到 Gerrit 中 的 代码 只 有 在 被 评审 和 接受 后 ， 才 真正 成 为 项 目的 一 部 分 。 增 加 
Gerrit 之 后 ，CIMCD 系 统 就 变 为 图 3-3 所 示 的 结构 。 
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图 3-3 Gerrit] J&CI/CD A A 


对 比 图 3-1， 显 著 的 差别 在 于 开发 者 (Developer) 不 再 直接 将 代码 推送 (Push) 到 代码 仓库 ， 而 是 需要 经 过 评审 者 (Reviewer) 的 批准 (Approve) 才能 真正 提交 (Submit) 。 


3.2.1 架构 


了 解 了 Gerrit 在 CMCD 系 统 中 的 位 置 和 主要 作用 后 ， 我 们 再 来 深入 内 部 分 析 一 下 它 的 基本 架构 ， 如 图 3-4 所 示 。 
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图 3-4 Gerrit% 


Gerrit 首 先是 一 个 变更 合 入 代码 库 之 前 的 预备 区 域 ， 方 便 检 查 。 同 时 它 还 为 评审 流程 提供 了 一 个 讨论 区 ， 用 于 收集 针对 每 次 变更 的 评论 ， 这 对 于 分 布 式 的 团队 尤其 有 用 。 对 于 在 同一 个 场所 工作 的 团 


， 这 个 工具 可 以 使 得 代码 评审 时 间 更 加 灵活 。 团 队 成 员 可 以 随时 提交 他 们 的 想法 ， 而 不 必 打 断 别人 或 被 别人 打 断 。 


Gerrit 支 持 多 种 用 户 认证 方式 ， 如 OpenID、OpenlD SSO、HTTP、HTTP_LDAP、OAUTH 等 ， 便 于 对 接 用 户 现 有 的 账号 系统 。 


Gerrit 拥 有 一 套 强大 的 用 户 访问 控制 系统 ， 可 以 精细 地 控制 代码 库 各 个 分 支 的 访问 权限 。 最 常用 的 权限 包括 变更 提交 、 代 码 合 入 ， 添 加 评审 标签 等 ， 后 面 的 小 节 我 们 会 作 进一步 的 说 明 。 理 论 上 通过 配 


置 权限 ， 甚 至 可 以 授权 用 户 略 过 代码 评审 过 程 直接 推送 代码 。Gerrit 的 用 户 访问 控制 功能 可 以 独立 于 评审 系统 ， 你 可 以 只 使 用 Gerrit 来 控制 代码 库 的 访问 权限 而 不 使 用 它 的 代码 评审 系统 。 通 常情 况 下 ， 即 便 
是 对 于 可 以 直接 推送 代码 的 用 户 ， 通 过 完整 的 评审 流程 合 入 代码 会 更 为 安全 。 


3.2.2 ”安装 


下 面 ， 我 们 从 环境 要 求 、 下 载 方式 及 程序 初始 化 等 方面 来 介绍 一 下 Gerrit 的 安装 过 程 。 
1. 环 境 要 求 

运行 Gerrit 需 要 JDK1.7[ 以 上 的 版 本 。 除 此 之 外 ， 还 需要 一 个 SQL 数据 库 用 于 存储 评审 中 的 元 数据 。 你 可 以 使 用 内 置 的 代入 式 H2 或 者 部 署 自己 的 MySQL 或 PostgreSQL。 
2. 下 载 Gerrit 

Gerrit 的 当前 版 本 和 历史 版 本 都 可 以 从 Gerrit 的 发 布 站 点 四 下 载 。 从 中 选择 一 个 版 本 的 *war 包 (下 文中 以 gerrit,war 指 代 ) 。 

如 果 你 更 偏好 从 代码 编译 ， 可 以 参考 官方 的 开发 者 文档 号 ]。 

3. 初 始 化 数据 库 

Gerrit 会 在 初始 化 阶段 要 求 你 指定 数据 库 类 型 。 

(1) H2 


H2 是 一 个 嵌入 式 的 数据 库 ， 在 Gerrit 中 使 用 不 需要 额外 的 配置 步骤 。 这 是 体验 Gerrit 的 最 简单 方法 ， 也 适用 于 规模 较 小 的 团队 使 用 。 但 对 于 规模 较 大 的 公司 来 说 ， 这 并 不 是 一 个 推荐 方案 。 因 为 H2 很 难 


在 Gerrit 离 线 的 情况 下 进行 交互 操作 ， 数 据 不 方便 备份 ， 也 无 法 配置 负载 均衡 。 


(2) PostgreSQL 


这 个 选项 要 比 H2 复 杂 ， 推 荐 用 于 大 规模 安装 。PostgresSQL 是 Gerrit 社 区 中 使 用 最 为 广泛 的 数据 库 后 端 。 


在 PostgreSQL 中 为 Gerrit 创 建 一 个 新 用 户 ， 指 定 密码 。 创 建 一 个 数据 库 reviewdb 用 于 存储 元 数据 ， 并 授予 该 用 户 此 数据 库 的 完全 访问 权限 。 


createuser --username-postgres -RD ElPS gerri t2 
createdb --username-postgres -E UTF-8 -O gerrit2 reviewdb 


上 述 命令 行 中 的 参数 含义 可 以 参考 PostgreSQL 文 档 内 。 


(3) MySQL 
这 个 选项 也 同样 比 H2 复 杂 ， 与 PostgreSQL 一 样 同 样 推 荐 用 于 大 规模 安装 。 


创建 一 个 新 用 户 ， 指 定 密码 ， 创 建 一 个 数据 库 用 于 存储 元 数据 ， 并 授予 该 用 户 完全 的 访问 权限 ， 如 代码 清单 3-1 所 示 。 


代码 清单 3-1 _ MySQL 初始 化 


CREATE USER 'gerrit2'G8'localhost' IDENTIFIED BY 'secret'; 
CREATE DATABASE reviewdb; 

GRANT ALL ON reviewdb.* TO 'gerrit2'G'localhost'; 
FLUSH PRIVILEGES; 


在 shell 下 运行 MySQL 客 户 端 ， 然 后 执行 相应 命令 即 可 。 这 里 的 示例 适用 于 MySQL 和 Gerrit 安 装 在 同一 个 节点 。 关 于 MySQL 的 更 多 信息 可 以 参考 MySQL 文 档 中 ]。 
(4) 其 他 

Gerrit 也 支持 Oracle、DB2、SAP MaxDB 等 ， 配 置 方法 可 以 参考 官方 文档 中 关于 数据 库 创建 [的 部 分 

4. 初 始 化 Gerrit 站 点 


Gerrit 以 网 站 的 形式 对 外 提供 服务 ， 在 使 用 前 需要 进行 一 些 初始 化 工作 。Gerrit 的 配置 文件 、 服 务 器 的 SSH 密 钥 以 及 受 控 的 Git 仓 库 都 保存 在 一 个 本 地 目录 里 ， 通 常 被 称 作 $site_path。 如 果 使 用 了 H2 数 
据 库 ， 那 么 数据 文件 也 保存 在 该 目录 下 。 


此 外 ， 你 需要 选择 一 个 保存 Git 仓 库 的 目录 ， 既 可 以 是 一 个 $site_path 下 的 相对 路 径 ， 也 可 以 是 系统 的 绝对 路 径 。 


初始 化 一 个 新 的 站 点 目录 通过 运行 init 命 令 来 完成 。 目 标 路 径 由 -d 选 项 指定 。 此 外 推荐 为 Gerrit 创 建 一 个 专门 的 用 户 用 于 执行 这 些 命 


sudo adduser gerrit2 
sudo su gerrit2 


java -jar gerrit.war init -d /path/to/your/gerrit application directory 


PX. 
Qus 
ia 主意 


如 果 gerrit2 用 户 没有 目标 路 径 的 访问 权限 ， 那 么 你 需要 手工 创建 目录 ， 并 把 所 有 权 设 置 为 gerrit2 用 户 。 


如 果 使 用 一 个 交互 终端 运行 ， 那 么 init 命 令 会 提示 一 系列 的 配置 问题 。 如 果 所 在 的 终端 不 支持 交互 ， 那 么 Gerrit 会 自动 选择 一 些 合理 默认 选项 ， 并 使 用 H2 骨 入 式 数 据 库 。 在 初始 化 过 程 结 束 后 ， 你 可 以 打 
开 配 置 文件 $site_path/etc/gerrit.conf ig 查 看 配置 信息 。 


在 init 命 令 的 运行 过 程 中 ， 可 能 需要 额外 下 载 一 些 JAR 包 来 支持 可 选 的 功能 。 万 一 下 载 失败 ， 屏 幕 上 会 打印 目标 URL， 等 待 用 户 手 工 下 载 后 放 到 指定 位 置 。 


初始 化 阶段 结束 后 ， 守 护 进程 会 自动 在 后 台 启动 ， 并 打开 浏览 器 访问 站 点 : 


Initialized /home/gerrit2/review site 

Executing /home/gerrit2/review site/bin/gerrit.sh start 

Starting Gerrit Code Review: OK 

aiting for server to start http://www.hzcourse.com/resource/readBook?path-/openresources/teach ebook/uncompressed/17933/OEBPS/Text/... OK 
Opening browser http://www.hzcourse.com/resource/readBook?path-/openresources/teach ebook/uncompressed/17933/OEBPS/Text/... 


打开 浏览 器 后 ， 通 过 Web 界 面 登录 Gerrit。 当 第 一 个 用 户 登 录 并 注册 时 ， 系 统 会 自动 创建 一 个 账号 ， 归 属于 拥有 全 部 权限 的 管理 员 组 ， 人 允许 其 通过 Web 和 SSH 进 行 管 理工 作 ， 后 续 的 用 户 会 被 自动 注册 
为 非特 权 用 户 。 


5. 开 发 模式 
我 们 可 以 通过 Docker 快 速 搭建 一 个 开 箱 即 用 的 Gerrit 服 务 器 ， 使 用 了 内 置 的 H2 数 据 库 和 开发 账号 : 


docker run -ti -p 8080:8080 -p 29418:29418 gerritcodereview/gerrit 


这 个 镜像 可 以 直接 用 于 开发 和 学 习 环境 ， 如 果 想 应 用 于 生产 环境 ， 还 需要 定制 配置 文件 ， 挂 载 外 部 存储 等 。 


[1] http://www.oracle.com/technetwork/java/javase/downloads/index.html 

[2] https:/ /www.gettitcodereview.com/download/index.html o 

[3] https:/ /gettit-documentation.storage.googleapis.com/Documentation/2.14.7 / dev-readme.html o 
[4] http:/ /www.postgtesql.org/docs/9.1 /interactive/index.html. 

[5] http:/ /dev.mysql.com/doc/ o 


[6] https:/ /gettit-documentation.storage.googleapis.com/Documentation/2.14.7 /install.htmlzzcreatedb. 


32.3 ”项 目 配置 


Gerrit 的 配置 选项 众多 ， 我 们 在 此 介绍 一 下 最 常用 的 几 个 方面 ， 包 括 项 目 、 分 支 、 标 签 和 权限 等 。 


1. 创 建 项 目 


新 项 目 可 以 通过 Web 界 面 上 的 Projects 一 Create Project 进 行 ， 如 图 3-5 所 示 。 注 意 ， 这 个 菜单 项 只 对 拥有 该 权限 的 用 户 可 见 。 在 开发 环境 中 ， 我 们 可 以 登录 为 admin 用 户 ， 拥 有 全 部 系统 权限 。 


All My Projects People Plugins Documentation 
List Create New Project 


Create Project 


Project Name: ‘cibook 

Rights Inherit From: | All-Projects 

( Create initial empty commit 

Only serve as parent for other projects 
| Create Project 


图 3-5 “在 Gettit 中 创建 项 目 
此 外 ， 也 可 以 通过 REST 或 SSH 接 口 创建 项 目 。 


以 SSH 为 例 ， 在 实验 环境 中 创建 一 个 新 的 名 为 tools/gerrit 的 项 目 : 


ssh -p 29418 admin@localhost gerrit create-project tools/gerrit.git 


Que 
你 必须 先 将 SSH 公 和 铀 添加 到 Gettit 对 应 用 户 的 账号 (Jeadmin) 才能 正常 登录 。 
完整 的 参数 说 明 可 以 参考 REST 接 口 创建 项 目 (J 和 SSH 命 令 创 建 项 目 [ 包 相关 文档 。 如 果 想 了 解 Gerrit 的 内 部 工作 机 制 ， 也 可 以 尝试 手工 创建 项 目 。 


在 Gerrit 的 基础 路 径 (配置 项 gerrit.basePath) 下 建立 一 个 Git 仓 库 : 


git --git-dir-$base path/tools/project.git init 


如 果 需 要 开启 匿名 git:// 协 议 访 问 ， 则 需要 建立 一 个 空 文件 git-daemon-export-ok: 


touch $base path/tools/project.git/git-daemon-export-ok 


然后 在 Gerrit 中 注册 该 项 目 ， 可 以 通过 重启 服务 ,或 者 强制 刷新 project_list 缓 存 : 


ssh -p 29418 admin@localhost gerrit flush-caches --cache project list 


2. 项 目 选项 


项 目 配置 可 以 通过 网 页 进行 ， 如 图 3-6 所 示 。 


Project Options 

State: | 

Submit Type: Merge if Necessa 
Allow content merges: 
Create a new change for every commit not in the target branch: . INHERIT (false) * 
Require Change-1d in commit message: INHERIT (true) 
Reject implicit merges when changes are pushed for review: INHERIT (false) $ 
Set all new changes private by default: ' INHERIT (false) 4 


Enable adding unregistered users as reviewers and CCs on changes: | INHERIT (false) $ | 
Match authored date with committer date upon submit: INHERIT (false) n 
Maximum Git object size limit: 


图 3-6 ”Gettit 项 目 配置 选项 
其 中 主要 的 配置 选项 说 明 如 下 : 
(1) 状态 State 
定义 项 目的 全 局 状态 。 一 个 项 目 可 以 有 如 下 几 个 状态 : 
+ Active 


项 目 处 于 活跃 状态 ， 用 户 可 以 按照 各 自 的 权限 访问 项 目 。 


项 目 处 于 只 读 状 态 ， 所 有 写 操作 被 禁止 ， 即 便 用 户 拥有 推送 变更 的 权限 操作 也 会 失败 。 

只 读 状 态 通 常用 来 临时 关闭 一 个 项 目 ， 这 样 你 可 以 保留 所 有 的 权限 设置 不 变 。 需 要 重新 启用 时 ， 只 需要 将 项 目 状 态 重新 设置 为 Active。 

另外 一 个 使 用 场景 是 项 目 被 迁移 到 其 他 位 置 。 你 希望 所 有 的 开发 活动 都 在 新 项 目下 进行 ， 老 项 目 仅 作 参 考 ， 此 时 需要 防备 有 人 不 小 心 提交 变更 到 老 项 目 。 
- Hidden 

项 目 处 于 隐藏 状态 ， 只 对 其 所 有 者 可 见 。 其 他 用 户 即便 拥有 读 的 权限 也 无 法 访问 。 

(2) 提交 类 型 Submit Type 

设置 Gerrit 可 用 的 变更 提交 方式 。 通 常情 况 下 ， 只 有 该 变更 所 有 的 依赖 都 被 同时 提交 才能 成 功 合 入 ， 但 也 有 一 些 例外 的 情况 ， 下 文 会 做 介绍 。 

”Inhhetit 


这 个 是 新 建 项 目的 默认 选项 ， 可 以 通过 设置 全 局 的 defaultSubmitType 重 载 。 在 这 个 配置 下 ， 来 自 于 父 项 目的 提交 类 型 会 被 继承 。 在 最 顶层 的 All-Projects 里 ， 由 于 没有 项 目 可 被 继承 ,这 个 选项 等 同 于 
Merge If Necessary, 


- Fast Forward Only 

这 个 方式 将 不 会 产生 合并 提交 ， 所 有 的 合并 操作 都 必须 在 本 地 完成 ， 然 后 才 可 以 上 传 到 Gerrit 中 评审 。 

变更 必须 是 目标 分 支 的 严格 超 集 才能 被 合 入 ， 也 就 是 说 ， 变 更 的 祖先 中 必须 包含 目标 分 支 的 顶端 ， 而 不 是 从 基于 某 个 历史 版 本 产生 分 又。 
- Merge If Necessaty 

如 果 变 更 是 目标 分 支 的 严格 超 集 ， 那 么 分 支 会 被 快速 推进 到 该 变更 。 否 则 的 话 ， 自 动产 生 一 个 合并 提交 。 这 个 与 经 典 的 git mergeskgit merge--ff 行 为 一 致 。 
- Always Merge 

总 是 产生 一 个 合并 提交 ， 即 便 该 变更 是 目标 分 支 的 严格 超 集 。 这 个 行为 与 git merge--no-ff 一 致 ， 当 项 目 采 用 git log--f irst-parent 来 跟踪 合 入 历史 时 比较 有 用 。 
- Cherry Pick 

总 是 将 变更 摘出 ， 并 应 用 到 分 支 的 顶端 ， 而 忽略 其 原来 的 基线 。 

在 这 个 方式 下 ，Gerrit 会 自动 在 变更 被 批准 时 附加 一 段 内 容 到 提交 信息 ， 其 中 包含 原 变更 的 Web 地 址 。 提 交 者 被 设置 为 合 入 者 ， 作 者 信息 仍 保留 为 原 补丁 的 作者 。 
- Rebase If Necessary 


如 果 变 更 是 目标 分 支 的 严格 超 集 ， 那 么 分 支 会 被 快速 推进 到 该 变更 。 否 则 的 话 ， 该 变更 被 变更 基线 ， 然 后 再 将 分 支 快 速 推 进 到 此 变更 。 


Gerrit 处 理 合并 时 ， 默 认 只 有 路 径 不 冲突 的 时 候 才 可 能 成 功 。 在 被 合并 的 双方 都 修改 了 同样 的 文件 时 就 会 产生 路 径 冲突 。 

- Rebase Always 

这 个 方式 与 Rebase If Necessary 基 本 相同 ， 但 总 是 创建 一 个 新 的 补丁 ， 即 便 可 以 执行 快速 推进 。 与 Cherry Pick 类 似 ， 这 个 会 保留 最 终 被 合并 提交 的 各 种 脚注 信息 ， 如 Changeld 等 。 
如 果 Allow content merge 被 使 能 ，Gerrit 会 在 路 径 冲 突 时 尝试 进行 内 容 合并 。 


(3) 其 他 选项 


项 目 设置 里 还 有 一 些 其 他 选项 ， 可 能 随 版 本 的 不 同 略 有 差别 ， 具 体 含义 可 以 参考 官方 文档 中 的 项 目 选 项 列表 上 3]。 


(1) 分 支 创 建 
在 项 目 中 创建 分 支 有 好 几 种 方式 : 
: 在 Web 界 面 的 Projects 一 List 一 {project} 一 Branches 里 创建 。 
: 通过 Create Branch 这 个 REST 接 口 创建 。 
: 通过 create-branch 这 个 SSH 命 令 创建 。 
` 通过 git 客 户 端 将 提交 推送 到 一 个 不 存在 的 分 支 。 
创建 分 支 需 要 拥有 Create Reference 访 问 权限 。 此 外 ， 项 目 所 有 者 和 Gerrit 管 理 员 可 以 通过 Web 界 面 或 者 REST 接 口 创建 分 支 , 不 受 Create Reference 权 限 的 限制 。 
在 使 用 Web 界 面 、REST 接 口 或 者 SSH 命 令 这 三 种 方式 创建 分 支 时 ， 分 支 只 能 建立 在 已 经 存在 于 仓库 的 提交 上 。 如 果 分 支 名 不 是 以 refs/ 开 头 的 ， 那 么 会 被 自动 加 上 refs/heads 前 缀 。 
分 支 的 起 始点 可 以 是 任意 有 效 的 SHA-1 表 达 式 ， 只 要 可 以 被 解析 成 提交 即 可 ， 缩 略 的 SHA-1 不 被 支持 。 


我 们 以 SSH 命 令 为 例 ， 在 实验 环境 中 创建 一 个 新 的 分 支 : 


ssh -p 29418 admin@localhost gerrit create-branch tools/gerrit newbranch master 


上 述 命令 的 效果 就 是 在 tools/gerrit 项 目 上 基于 master 分 支 创建 新 的 分 支 newbranch。 
(2) 分 支 删除 

分 支 删 除 也 有 好 几 种 方式 : 
- 在 Web 界 面 的 Projects 一 List 一 {project} 一 Branches 里 创建 。 
: 通过 Delete Branch 这 个 REST 接 口 创建 。 


E 通过 git 客 户 端 创建 : 


$ git push origin --delete refs/heads/«branch-to-delete» 


另外 一 个 方法 是 强制 推送 空 分 支 到 一 个 已 经 存在 的 分 支 : 


$ git push --force origin :refs/heads/«branch-to-delete» 


(3) 默认 分 支 
远程 仓库 的 默认 分 支 由 它 的 HEAD 引 用 定义 。 克 隆 一 个 仓库 时 ，Git 会 为 默认 分 支 创 建 一 个 本 地 分 支 并 检 出 。 
项 目 所 有 者 可 以 设置 HEAD: 

- 在 Web 界 面 的 Projects 一 List 一 {project} 一 Branches 里 设置 。 

- 通过 setHEAD 这 个 REST 接 口 设置 。 
4. 标 签 管理 


Gerrit 中 没有 提供 专门 的 标签 管理 接口 ， 创 建 标签 可 以 通过 Git 命 令 完成 ， 用 户 需 要 具备 相应 的 权限 。 前 面 3.1.4 节 提 到 标签 分 为 两 种 : 轻 量 型 标签 在 Git 中 的 实现 与 普通 分 支 类 似 ， 因 此 只 需要 授予 
refs/tags/* 的 Create Reference 权 限 即 可 ; 对 于 带 注 记 的 标签 ， 对 应 的 权限 是 Create Annotated Tag， 如 果 需 要 推送 的 标签 是 别人 创建 的 (例如 同步 上 游 Git 仓 库 时 ) ， 那 么 还 需要 具备 Forge Committer 
Identify 的 权限 。 有 具体 的 Git 命 令 如 下 : 


基于 stable 分 支 创建 带 注 记 标签 : 
git tag -a -m "Release v1.0" v1.0 stable 


向 Git 仓 库 推送 标签 : 


git push ssh://USERGHOST:PROT/PROJECT tag v1.0 


其 中 tag v1.0 的 效果 与 refs/tags/v1.0:refs/tags/v1.0 一 样 。 
删除 或 者 覆盖 已 经 存在 的 标签 则 需要 针对 refs/tags* 的 Push 权 限 ， 并 同时 勾 选 force 选 项 。 


5. 权 限 配置 


权限 配置 可 以 通过 Web 界 面 进行 : 


1) 在 Web 界 面 上 选择 Projects 一 List。 


2) 找到 需要 管理 的 项 目 并 点 击 进入 。 


3) 点 击 Access 菜 单项 。 


4) 点 击 Edit 进 入 编辑 模式 。 


5) 修改 完成 之 后 点 击 Save Changes 保 存 ， 此 时 你 可 以 输入 一 些 提交 信息 来 记录 这 次 权限 变更 的 原因 。 如 果 没 有 直接 修改 的 权限 ， 保 存 之 后 会 进入 评审 流程 。 


项 目的 权限 被 保存 在 项 目 Git 仓 库 的 一 个 特殊 分 支 下 ， 即 refs/meta/conf ijg。 这 个 分 文 里 有 一 个 project.conf ig 文 件 保存 了 访问 权限 信息 。 如 果 熟 悉 配置 文件 的 语法 ， 你 也 可 以 直接 修改 这 个 文件 来 维护 


项 目 权限 。 样 例文 件 如 代码 清单 3-2 所 示 。 


代码 清单 3-2 ”Gerrit 权 限 配置 


[project] 


description = Rights inherited by all other projects 
[access "refs/*"] 

read = group Administrators 
[access "refs/heads/*"] 


abel-Here = -1http://www.hzcourse.com/resource/readBook?path-/openresources/teach ebook/uncompressed/17933/OEBPS/Text/..*1 group Administrators 


label-Your-: 

[capability] 

administrateServer = group Administrators 
[receive] 

requireContributorAgreement = true 


[label "Your-Label-Here"] 


va] 
va] 


Lue 


function = MaxWithBlock 


Your -1 Description 


Lue 


val 


How gu 
十 o 


Lue 


Your No score Description 


Your +1 Description 


这 个 文件 的 格式 与 Git 配 置 文件 一 致 ， 将 选项 分 成 了 不 同 的 区 。 


.btroject 配 置 块 只 出 现 一 次 ， 保 存 项 目的 基本 描述 。 


:access 配置 块 需要 指明 匹配 模式 ， 配 置 了 各 类 分 支 的 访问 权限 ， 一 个 匹配 模式 只 能 配置 一 个 access 配 置 块 。 


capability 配 置 块 只 出 现在 All-Projects 仓 库 下 ,保存 了 适用 于 全 局 的 一 些 配 置 。 


: receive 配 置 块 对 于 每 个 项 目 只 出 现 一 次 ， 配 置 了 Gerrit 接 收 补 丁 的 条 件 ， 如 上 述 示 例 中 要 求 用 户 必须 同意 贡献 者 协议 ， 否 则 所 提 的 补丁 将 不 被 接受 。 


. label 配 置 块 可 以 在 一 个 项 目 里 出 现 多 次 ， 除 了 内 建 的 Code-Review 和 Vetified， 你 可 以 增加 一 些 自 定义 的 标签 ， 


和 描述 都 是 可 以 自 定 义 的 。 


默认 情况 下 ， 配 置 文件 所 在 的 refs/meta/conf ig 分 支 在 克隆 Git 仓 库 时 不 会 被 取 到 本 地 ， 我 们 需要 通过 Git 命 令 显 式 获取 ， 如 代码 清单 3-3 所 示 。 


代码 清单 3-3 


通过 Git 获 取 配 置 文件 


$ git fetch gerrit refs/meta/config 


remot 
remot 


te: Counting objects: 3, done 
te: Finding sources: 100% (3/3) 


remote: Total 3 (delta 0), reused O (delta 0) 
Unpacking objects: 100% (3/3), done. 

From ssh://localhost:29418/tools/gerrit 

* branch 
$ git checkout -b config FETCH HEAD 
Switched to a new branch 'config' 


上 述 命令 首先 获取 远 端 的 refs/meta/conf ig 分 支 ， 默 认 保 存在 FETCH_HEAD 下 ， 然 后 检 出 该 引用 到 本 地 的 conf ig 分 支 。 完 成 修改 后 即 可 将 变更 推送 回 远 端 : 


refs/meta/config -> FETCH HEAD 


git push origin config:refs/meta/config 


[1] https://gertit-teview. googlesource.com/Documentation/rest-api-projects.html#create-projecto 


[2] https:/ /gettit-teview.googlesoutce.com/Documentation/cmd-create-project.html o 


[3] https://gerrit-documentation.storage.googleapis.com/Documentation/2.14.7 /project-conf iguration.html# project options. 


3.2.4 CI/CD 系 统 对 接 


至 此 ， 我们 对 Git 和 Gerrit 的 基本 概念 和 架构 有 了 初步 对 了 解 ， 为 了 让 提交 的 代码 能 够 触 友 CI/CD 任 务 ， 我 们 还 需要 完成 与 CI/CD 系 统 的 对 接 ， 比 较 常 见 的 有 Jenkins 和 Zuul。 


详细 介绍 ， 此 处 先 简 单 介 绍 下 Gerrit 这 部 分 的 配置 。 


1. 对 接 持续 集成 系统 (Jenkins) 


Gerrit 可 以 通过 插件 [与 Jenkins 对 接 ， 实 现代 码 提交 后 自动 触发 构建 过 程 。 


1) 在 Gerrit 中 为 Jenkins 创 建 一 个 用 户 ， 并 为 其 设置 SSH 密 钥 。 


2) 在 Web 界 面 的 Admin 一 Groups 一 Non-lteractive Users 里 加 入 该 用 户 。 


3) 在 Web 界 面 的 Admin 一 Projects 一 … 一 Access 一 Edit 里 配置 权限 。 


配置 样 例如 代码 清单 3-4 所 示 。 


代码 清单 3-4 Gerrit 对 接 CI 权 限 配置 


Re 


ference: 


ref 


s/* 


如 OpenStack 社 区 里 增加 了 Workflow 标 签 用 于 触发 代码 合 入 流程 。 所 有 标签 的 功能 、 取 值 


我 们 会 在 第 4 章 和 第 5 章 分 别 


Read: ALLOW for Non-Interactive Users 
Reference: refs/heads/* 
Label Code-Review: -1, +1 for Non-Interactive Users 
Label Verified: -1, +1 for Non-Interactive Users 


具体 可 以 参考 Gerrit 文 档 中 关于 访问 控制 | 部 分 的 内 容 。 
在 Jenkins 中 ， 需 要 配置 Gerrit 服 务 的 访问 方式 以 及 触发 条件。 这 些 触发 条 件 都 对 应 于 Gerrit 中 的 特定 事件 ， 如 : 

: Draft Published: 变更 从 draft 状 态 变 为 new。 

- Patchset Created: 新 的 补丁 集 被 添加 到 某 一 变更 ， 这 个 是 最 常用 的 触发 方式 之 一 。 

: Change Merged: 变更 被 合 入 Gettit 服 务 器 ， 这 个 通常 用 于 触发 发 布 流程 。 

: Comment Added: 评论 被 添加 到 某 一 变更 ， 这 个 通常 用 于 手动 触发 构建 过 程 ， 如 OpenStack 里 的 tfecheck。 

: Ref Updated: 当 一 个 Git 引 用 被 更 新 时 ， 除 了 通过 正常 的 评审 流程 合 入 代码 之 外 ， 增 加 tag、 创 建 分 支 等 操作 也 会 触发 此 事件 。 
2. 对 接 门 控 系统 (Zuul) 


在 OpenStack 的 CI/CD 系 统 中 ，Gerrit 并 非 直接 与 Jenkins 对 接 ， 而 是 引入 了 另外 一 个 系统 Zuul 来 进行 项 目 管控 。 简 单 来 说 ，Zuul 会 侦 听 Gerrit 的 事件 流 ， 然 后 触发 Jenkins 上 的 构建 任务 。 具 体 请 参见 第 
5 章 。 


[1] https:/ /wiki.jenkins.io/display/J ENKINS /Getrit + Trigger. 


[2] https:/ /gettit-teview.googlesource.com/Documentation/access-conttrol. html. 


33 “本章 小 结 


在 本 章 中 ， 我 们 介绍 了 Git 和 Gerrit 的 基本 功能 和 它们 在 CIMCD 中 扮演 的 角色 。 


Gerrit 对 接 开发 者 和 Git 仓 库 ， 提 供 了 身份 验证 和 访问 控制 功能 ,保存 评审 历史 ， 并 输出 事件 流 以 触发 CI/CD 构 建 任务 。 它 是 整个 自动 化 流水 线 的 起 点 ， 吹 响 了 DevOps 的 号 角 。 


第 4 章 ”持续 集成 系统 (Jenkins) 


所 谓 持续 集成 ， 就 是 指 频繁 地 (一 天 多 次 甚至 几 十 次 ) 将 代码 集成 到 主干 。 一 个 完整 的 持续 集成 系统 必须 包括 : 
: 代码 存储 库 : 即 版 本 控制 软件 来 保障 代码 的 可 维护 性 ， 同 时 作为 构建 过 程 的 素材 库 。 

:自动 构建 过 程 : 包括 自动 编译 、 分 发 、 部 署 和 测试 等 。 

“ 持续 集成 服务 器 : 实时 监控 代码 存储 库 的 活动 ， 并 启动 自动 构建 过 程 。 


Openstack 使 用 Jenkins 来 作为 持续 集成 服务 器 。 


4.1 Jenkins 介 绍 


Jenkins 的 前 身 是 Hudson， 是 Sun 公 司 于 2004 年 夏天 开发 的 ，2005 年 2 月 底 开 源 并 发 布 了 第 一 个 版 本 。Hudson 在 2008 年 左右 就 已 经 基本 取代 了 CruiseControl 和 其 他 开源 的 构建 服务 器 ， 并 在 2008 年 5 
月 的 JavaOne 大 会 上 ， 获 得 开发 人 员 解 决 方案 分 类 的 Duke 选 择 奖 。 


2009 年 ，Oracle 收 购 了 Sun， 之 后 Oracle 把 Hudson 名 字 变 成 注册 商标 并 开始 作为 商业 软件 开发 。2011 年 年 初 ， 开 发 社区 通过 投票 将 项 目 改 名 为 Jenkins， 持 续 维护 。 目 前 ， 在 GitHub 上 的 Jenkins 组 织 
有 600 多 个 项 目 成 员 和 1900 多 个 公共 库 。 


4.1.1 Jenkins 是 什么 

Jenkins 是 一 个 用 Java 编 写 的 开源 的 广泛 用 于 持续 构建 的 可 视 化 Web 集 成 工具 。 它 支持 各 种 项 目 (各 种 开发 语言 如 Net、Ruby、PHP、Python 等 ) 的 自动 化 编译 、 打 包 、 分 发 和 部 署 。 完 全 兼容 ant、 
maven、gradle 等 第 三 方 构建 工具 ， 同 时 能 与 SVN、CVS、Git 等 软件 配置 管理 工具 (SCM) 无 颖 集成 ， 也 直接 支持 第 三 方 源 码 托管 系统 ， 如 GitHub、GitLab、BitBucket 等 。 它 具有 如 下 优点 : 

- 易 用 性 : 支持 Windows、Linux、Mac 等 操作 系统 ， 提 供 可 视 化 Web 配 置 管理 。 

. 可 扩展 性 : 扩展 插件 涵盖 了 版 本 控制 、 构 建 工具 、UI 自 定义 、 事 件 通 知 等 。 

. 活跃 的 社区 : 大 量 的 用 户 和 插件 ， 足 见 应 用 的 广泛 性 和 社区 活跃 度 。 


. 稳定 的 版 本 支持 : 每 周 发 布 新 的 版 本 ， 每 12 周 发 布 一 个 稳定 的 Long Tem Support (LTS) 版 本 。 


4.1.2 Jenkins 工 作 原 理 


Jenkins 收 到 触发 构建 的 命令 后 ， 先 选择 一 个 合适 的 Slave， 并 将 待 构建 代码 拷贝 一 份 到 Slave， 然 后 根据 预定 义 的 自动 构建 脚本 执行 一 系列 任务 。Jenkins 触 发 构建 有 多 种 ， 最 常用 的 有 如 下 几 种 : 
` 版 本 控制 系统 中 有 新 的 变更 或 者 补丁 
“类似 Cron 的 定时 任务 
* 其 他 构建 完成 时 
`- 收 到 特定 的 URL 请 求 
1. 典 型 的 持续 集成 系统 


下 面 以 Jenkins+Gerrit 组 成 的 系统 为 例 来 说 明 一 个 典型 的 持续 集成 系统 (如 图 4-1 所 示 ) 是 如 何 工作 的 。 


e À 


Developer 


Slaves 


Reviewers 


J a 


图 4-1 Jenkins-Gettit 持 续集 成 系统 


1) 开发 者 从 代码 库 中 检 出 源 代码 ， 进 行 新 功能 开发 、 修 改 bug 或 者 更 新 文档 等 变更 。 

2) 开发 者 提交 新 的 变更 到 Gerrit。 

3) Gerrit 发 送 代码 库 变 更 消息 给 Jenkins。 

4) Jenkins 收 到 代码 库 变 更 消息 后 ， 根 据 构 建 任务 配置 选择 合适 的 Slave (slave 选 择 规则 请 参见 4.1.6 节 中 的 labels 描 述 ) 。 
5) Jenkins 远 程控 制 Slave 从 代码 库 Gerrit 中 检 出 变更 代码 ， 启 动 变更 验证 。 

6) Jenkins 把 变更 验证 结果 通过 投票 形式 通知 Gerrit。 

7) 其 他 开发 人 员 评审 变更 ， 并 投票 是 否 允 许 合 入 。 

8) 如 果 此 变更 被 Jenkins 及 其 他 开发 人 员 都 投票 通过 ， 则 Gerrit 把 此 次 变更 合 入 代码 库 。 

2.OpenStack Jenkins 实 践 


在 OpenStack CI 系统 中 ， 构 建 任务 通过 Zuul 触 发 调度 ， 而 Slave 则 是 通过 Nodepool 进 行动 态 的 注册 和 注销 。 组 件 之 间 的 交互 关系 如 图 4-2 所 示 。 


FTP 


RESTful 


图 4-2 Jenkins OpenStack CI 实践 


: JenkinsfeZuul: £4 A P Jenkinsi id Gearman4é& fF ZRH Zuul f 4£ 4-3: 2:27 f& , Jenkinsi JAWJobA X-443£48 k (包括 Job 名 称 和 Slave 名 称 ) 到 Geatman 服 务 器 ， 每 次 构建 任务 被 触发 时 ，Zuul 把 构建 任务 提交 
到 Gearman 服 务 器 ， 由 Gearman 根 据 Jenkins 注 册 的 Job 执 行 调度 。 


* Jenkinse Nodepool: Nodepool 根 据 Slave 相 关 的 配置 信息 及 Gearman 上 运行 的 Slave 状 态 (数目 及 类 型 等 ) 计算 出 需要 创建 的 Slave， 并 通过 RESTful 接 口 注册 给 Jenkins; 另 一 方面 每 次 构建 完成 之 
后 ，Jenkins 通 过 ZMQ 发 布 构建 完成 消息 ，Nodepool 收 到 消息 后 ， 通 过 RESTful 接 口 注销 Slave。 


-Jenkins 和 Logstash: 每 次 构建 完成 之 后 ，Jenkins 通 过 ZMQ 发 布 构建 完成 消息 ，Logstash 收 到 消息 之 后 ， 进 行 构建 日 志 的 采集 。 


本 章 主要 通过 典型 的 持续 集成 系统 (Gerrit-Jenkins) 对 Jenkins 的 应 用 进行 描述 ， 至 于 Jenkins 在 OpenStack CI 系统 中 的 实践 请 参见 第 10 章 。 


4.1.3 部署 Jenkins 


1. 安 装 Jenkins 

Jenkins 是 基于 Java 开 发 并 开源 的 自动 化 持续 集成 系统 ， 所 以 在 任何 支持 Java 的 操作 系统 或 平台 中 都 可 以 安装 Jenkins。 它 支持 War 包 和 容器 安装 方式 ， 具 体 的 安装 方法 见 下 文 描述 。 
(1) WAR 文 件 安装 

通过 War 包 安装 的 过 程 如 下 : 

1) 下 载 指 定 或 者 最 新 的 稳定 的 War 包 到 待 部 署 主机 的 指定 目录 。 

2) 打开 控制 终端 并 进入 到 下 载 目 录 。 

3) 执行 java-jar jenkins.war 命 令 启动 Jenkins。 

4) 通过 http://jenkins.cibook.oz:8080 链 接 ， 访 问 Jenkins。 

5) 等 待 Jenkins 启 动 完成 之 后 ， 在 访问 页 面 上 自动 进入 启动 后 引导 程序 。 


如 果 需 要 修改 Jenkins 监 听 端 口 ， 可 以 通过 设置 --httpPort 启 动 参 数 来 完成 ， 比 如 通过 运行 java-jar jenkins.war-httpPort=8711，Jenkins 就 监听 在 端口 8711 上 了 ， 这 时 候 需 要 通 
过 http://jenkins.cibook.o0z:8711 访 问 Jenkins 界 面 。 


(2) Docker 安 装 
Jenkins 也 提供 了 容器 化 的 使 用 方式 。 通 过 容器 启动 Jenkins 步 又 如 下 : 
1) 打开 控制 终端 。 

2) 通过 代码 清单 4-1 中 的 命令 下 载 并 启动 Jenkins 容 器 。 


代码 清单 4-1 ”启动 Jenkins 容 器 


docker run \ 
-u root \ 


-p 8080:8080 \ #a 

-p 50000:50000 \ #b 

-v jenkins-data:/var/jenkins home \ #c 

-v /var/run/docker.sock:/var/run/docker.sock \ 
jenkins/jenkins:latest 


其 中 : 
*-pjenkins port8080: 把 容器 内 部 Jenkins 的 监听 端口 8080 映 射 到 主机 的 jenkins_port 端 口 ， 可 以 通过 修改 jenkins_port 来 修改 主机 端口 。 比 如 ， 如 果 写 成 -p 49001:8080，Jenkins 的 监听 端口 就 变 成 了 49001。 
- -p slave_port:50000: Slave 和 Jenkins 通 信 的 TCP 端 口 。 同 上 ， 此 端口 也 是 可 以 被 修改 的 。 


:-vjenkins data:/var/jenkins home: 可 选 ,但 是 强烈 建议 使 用 ; 通过 Docket 卷 的 概念 把 Jenkins 配 置 数据 映射 到 主机 的 jenkins_data 目 录 。 如 果 不 加 入 此 上 映射， 每 次 Jenkins 重 启 都 会 是 一 个 新 的 实例 ， 老 的 数 


据 将 不 复 存 在 。 
3) 通过 http://jenkins.cibook.oz:8080 访 问 Jenkins 页 面 。 
4) 等 待 Jenkins 启 动 完 成 之 后 ， 就 进入 启动 后 引导 程序 。 
2. 启 动 后 引导 程序 
在 Jenkins 安 装 成 功 之 后 ， 就 进入 启动 后 引导 程序 流程 ， 这 一 流程 通过 一 系列 的 一 次 性 步骤 完成 解锁 Jenkins、 定 制 化 插件 及 产生 第 一 个 管理 员 用 户 ， 详 细 步 又 如 下 所 述 。 
(1) 解锁 Jenkins 


当 Jenkins 安 装 启动 之 后 ， 第 一 次 被 访问 的 时 候 ， 会 要 求 用 户 使 用 Jenkins 自 动 生成 的 密码 来 解锁 它 ， 这 样 做 是 从 安全 的 角度 出 发 迫使 用 户 新 创 一 个 用 户 名 密码 ， 如 图 4-3 所 示 。 


Getting Started 


Unlock Jenkins 


To ensure Jenkins is securely set up by the administrator, a password has been written 
to the log (not sure where to find it?) and this file on the server: 


/var/jenkins home/secrets/initialAdminPassword 


Please copy the password from either location and paste it below. 


Administrator password 


图 4-3 ”解锁 Jenkins 


如 果 是 以 War 包 方 式 启动 的 ， 这 个 密码 可 以 从 控制 终端 的 打印 日 志 中 获取 ， 也 可 以 根据 页 面 的 提示 到 存储 文件 中 获取 (linux 默 认 路 径 : /var/jenkins home/secrets/initialAdmin-Password) 。 如 果 
Jenkins 是 通过 Docker 启 动 的 ， 可 以 到 Docker 日 志 中 (通过 docker log) 获取 。 


(2) 定制 插件 
Jenkins 解 锁 之 后 即 进入 插件 定制 化 页 面 ， 这 步 主要 是 选择 初始 安装 插件 ， 系 统 提供 了 两 个 选项 : 


: Install suggested plugins: 安装 默认 的 插件 ，Jenkins 针 对 常用 应 用 场景 ， 提 供 了 一 系列 默认 的 安装 插件 。 在 不 知道 哪些 插件 需要 安装 的 情况 下 ， 可 以 选择 此 选项 ， 后 续 可 以 根据 需要 再 增加 或 者 删除 部 分 
插件 。 


: Select plugins to install: 安装 自 定义 插件 ， 如 果 你 非常 明确 需要 安装 哪些 插件 ， 默 认 的 插件 又 不 能 满足 需求 ， 可 以 选择 此 选项 。 


开始 安装 之 后 ， 会 有 一 个 进度 条 显示 当前 正在 安装 的 插件 及 安装 进度 ， 整 个 过 程 会 持续 几 分 钟 。 


(3) 创建 管理 员 用 户 


在 插件 安装 完成 之 后 ， 系 统 会 进入 创建 第 一 个 管理 员 用 户 页 面 ， 在 这 个 页 面 里 填 入 管理 员 用 户 的 用 户 名 和 密码 ， 之 后 即 可 用 此 用 户 访问 并 管理 Jenkins 了 。 当 然 ， 为 了 安全 考虑 ， 一 般 创建 一 些 用 户 并 根 
据 角 色 和 权限 进行 管理 ， 详 情 请 参见 4.1.5 小 节 。 


4.1.4 插件 管理 


Jenkins 的 插件 除了 在 前 面 介 绍 的 通过 启动 后 引导 程序 安装 之 外 ， 还 可 以 在 局 动 完 成 之 后 在 使 用 过 程 中 通过 Manage Jenkins 一 Manage Plugins 页 面 执行 安装 、 删 除 、 更 新 等 管理 操作 。 
1. 安 装 插件 
Jenkins 插 件 支 持 在 线 安装 ， 也 支持 离线 安装 。 通 过 Manage Jenkins 一 Manage Plugins 进 入 插件 安装 页 面 。 


图 4-4 以 安装 Gerrit Trigger 为 例 来 介绍 在 线 安装 方式 。 


Filter: | && gerrit 


Updates ^ Available ^ Installed ^ Advanced 


Install | Name 
Gerrit Verify Status Reporter Plugin 
Post test reports to Gerrit 


Gerrit Trigger 
integrates with Gerrit code review. 


sonar Gerrit Plugin 


Message Injector Plugin 


Plugin allows you to inject a custom message into Gerrit Trigger messages 


Install without restart Download now and install after restart A ; 
Update information obtained: 4 


图 4-4 安装 插件 


通过 Available 页 面 的 Filter 匹 配 待 安装 的 插件 ， 选 择 好 插件 之 后 点 击 Install without restart， 这 个 插件 就 安装 完成 了 。 


离线 安装 是 指 先 下 载 好 插件 的 hpi 文 件 ， 在 Advanced 页 面 通过 上 传 hpi 文 件 进 行 安装 的 方式 ， 这 里 不 再 详 加 说 明 ， 感 兴趣 的 读者 可 以 参考 官方 文档 [1]。 需 要 注意 的 是 ， 这 种 方式 安装 的 插件 需要 重启 
Jenkins 才 能 生效 。 


2. 配 置 插件 

许多 插件 安装 完成 之 后 ， 必 须 进 行 配置 才能 使 用 ， 其 相关 插件 的 配置 基本 都 是 通过 Manage Jenkins 一 Conf igure System 来 实现 的 ， 下 面 介 绍 几 个 常用 插件 的 配置 。 
(1) Gerrit Trigger 

Gerrit 的 配置 涉及 Gerrit 本 身 的 配置 和 Jenkins 上 Gerrit Trigger 揪 件 的 配置 两 部 分 ，Gerrit 的 配置 请 参见 第 3 章 。 


Gerrit Trigger 插 件 的 配置 路 径 与 其 他 插件 稍稍 不 同 ， 是 通过 Manage Jenkins 一 Gerrit-Trigger 进 入 的 。 如 果 是 第 一 次 配置 ， 点 击 页 面 左 上 角 的 Add New Server， 如 果 对 已 经 加 入 的 Gerrit 配 置 进行 修 
改 ， 则 点 击 图 4-5 中 Edit 下 面 的 图 标 。 


4 Back to Dashboard Global Configuration 


€ Add New Server No. of Receiving Worker Threads | 3 | e 
No. of Sending Worker Threads | 1 | e 


Bil Diagnostics 


图 4-5 Gerrit Servers 页 面 


进入 配置 页 面 之 后 进行 如 图 4-6 所 示 的 配置 。 


Gerrit Connection Setting 


Name 


No Connection On Startup 


Hostname 


Frontend URL 


SSH Port 


Proxy 


Username 


E-mail 


SSH Keyfile 


Nar/jenkins home/.ssh/id rsa 


SSH Keyfile Password 


O Build Current Patches Only 


图 4-6 He E Gerrit Server 


主要 配置 项 合 义 如 下 : 


: Name: Gettit 服 务 器 的 名 字 。 


: Hostname: Gettit 服 务 器 的 主机 名 或 者 IP 地 址 。 


- Frontend URL: 访问 Gerrit 页 面 的 URL。 


. SSH Port: SSH 方 式 下 载 代码 使 用 的 端口 号 ， 默 认 是 29418， 在 此 示例 环境 中 使 用 的 是 30082 端 口 。 


* Username eSSH Keyftle: SSH} ly] Gerrit tg Jf] P fe 25 4]. 
: Test Connection: 配置 完成 后 点 击 此 按钮 检查 配置 是 否 正 确 ， 如 果 正 确 则 会 显示 Success。 


此 外 ， 为 了 实时 返回 构建 过 程 及 自动 返回 构建 结果 给 Cerrit， 还 需要 配置 Gerrit Reporting Values (如 图 4-7 所 示 ) 和 Gerrit Verifted Commands (如 图 4-8 所 示 ) 。 


Gerrit Reporting Values 


Verify 
Started 


Successful 


Failed 


Unstable 


Mot Built 


图 4-7 Gerrit Reporting Values 
Gerrit Verified Commands 


Started gerrit review «CHANGE-,«PATCHSETS» --message 'Build 
Started «BUILDURL- «STARTED STATS- --verified [27 


| «VERIFIED» --code-review «CODE REVIEW- 


zt 


Successful gerrit review «CHANGE-,«PATCHSET» --message 'Build 


Successful «BUILDS STATS-' --verified «VERIFIED- -= 
| code-review -«CODE REVIEW- E 


Falled gerit review «CHANGE-,«PATCHSET» --message 'Build 
Failed «BUILDS STATS» --verified «VERIFIED --cade- © 
review <CODE_REVIEW> 5 


Unstable gerrit review <CHANGE> <PATCHSET> --message 'Build 
Unstable «BUILDS. STATS» --verified «VERIFIED» -- 
code-review «CODE. REVIEW» 


L 


mE gerrit review «CHANGE», «PATCHSET» --message 'No 
Builds Executed «BUILDS STATS-' --verified 


eVERIFIED- --code-review «CODE REVIEW 


图 4-8 Gerrit Verified Commands 
£t Gerrit Reporting Values 和 Gerrit Verifted Commands 两 项 配置 ， 可 达到 如 下 效果 : 
1) 构建 开始 : Jenkins 向 Gerrit 发 送 Build Started 和 Verifted= 0 的 消息 ，Gerrit 收 到 消息 后 添加 一 条 构建 开始 的 评审 记录 ， 并 清除 verified 值 。 
2) 构建 结束 并 成 功 : Jenkins 向 Gerrit 发 送 Build Successful 和 Verifted+1 的 消息 ，Gerrit 收 到 消息 后 添加 一 条 构建 成 功 的 评审 记录 ， 并 置 Gerrit 上 Verified 为 +1。 
3) 构建 结束 并 失败 : Jenkins 向 Gerrit 发 送 Build Failed 和 Verifted-1 的 消息 ，Gerrit 收 到 消息 后 添加 一 条 构建 失败 的 评审 记录 ， 并 置 Gerrit 上 Verified 为 -1。 


4) 构建 不 稳定 : Jenkins 向 Gerrit 发 送 Build Unstable 和 Verifted-1 的 消息 ，Gerrit 收 到 消息 后 添加 一 条 构建 不 稳定 的 评审 记录 ， 并 置 Gerrit 上 Verified 为 -1。 


5) 如 果 构 建 没有 启动 : Jenkins 不 会 向 Gerrit 发 送 消息 。 
配置 完成 ， 点 击 Ssave， 就 会 自动 返回 到 图 4-5 所 在 的 页 面 ， 这 时 点 击 Status 栏 的 球形 图 标 ， 如 果 球 的 颜色 标志 成 绿色 ， 则 证 明 此 Gerrit 服 务 器 对 接 成 功 ， 可 以 使 用 了 。 


(2) Gearman Plugin 


Gearman Plugin 是 Jenkins 和 Gearman 进 行 通信 的 桥梁 ， 在 Manage Jenkins Conf igure System 一 Gearman Plugin Conf ig 按 照 如 图 4-9 所 示 配 置 。 


Gearman Plugin Config 


rman Server Host | i 
Gearman Server Hos gearman.cibook.oz 


Gearman Server Port 4730 


Select to enable Gearman plugin, Unselect to disable 


Enable Gearman 


图 4-9 BG E Gearman 


配置 完成 之 后 ， 可 点 击 Test Connection 按 钮 来 测试 链接 是 否 成 功 。 


(3) ZMQ Event Publisher Plugin 
Jenkins 通 过 ZMQ Event Publisher Plugin 发 布 Job 启 动 、 停 止 等 事件 到 Nodepool， 其 在 Manage Jenkins 一 Conf igure System 一 ZMQ Event Publisher 的 配置 如 图 4-10 所 示 。 


ZMQ Event Publisher 


Enable on all Jobs 
Check if we should publish events for all jobs. 


TCP port to publish on 8888 


Bind to this TCP port and publish events on it 


E440 配置 ZMQ 
(4) SCP Pulisher Plugin 
OpenStack Cl 系统 中 持续 集成 的 日 志 通 过 SCP 转 存 到 日 志 服 务 器 中 。SCP Publisher Plu-gin 是 Jenkins 上 负责 此 转 存 操作 的 载体 ， 其 在 Manage Jenkins 一 Conf igure System 一 SCP repository hosts 


的 配置 如 图 4-11 所 示 。 


配置 完成 之 后 ， 可 以 通过 Test Connection 测 试 其 连通 性 。 


SCP repository hosts 


SCP sites 


Displayname | LogServer 


Hostname log.cibook.oz 


Port 


/srv/static 


Root Repository Path | 


User Name jenkins 


Password/Passphrase | | e 


Keyfile 


| Harllib/jenkins/.ssh/id rsa 


SCP sites that projects will want ta connect 


图 4-11 配置 SCP Publisher 


(5) SSH Credentials Plugin 


OpenStack Cl 系统 中 ，Jenkins 和 Slave 的 通信 安全 通过 使 用 SSH Credentials 来 保障 ， 在 安装 完 SSH Credentials Plugin 之 后 ， 点 击 Crendentials 一 System 一 Global credentials A Global 
Crendentials 页 面 ， 然 后 点 击 Add Credentials 创 建新 的 Credential， 见 图 4-12。 


会 Back to credential domains Kind | SSH Username with private key 


@ Add Credentials Scope | Global (Jenkins, nodes, items, all child items, etc) 


Username jenkins 


Private Key @ Enter directly 
Key | 


Z 
| 
©) From a file on Jenkins master 


( From the Jenkins master ~/.ssh 


Passphrase | 


ID | test jenkins 


Description | add a test credentials for cibook " 


图 4-12 4] X£ Credentials 
: Kind: 选择 Credentials 类 型 ， 可 以 是 用 户 名 密码 格式 ， 也 可 以 是 SSH 密 钥 格 式 。 
“ Scope: 选择 Credentials 的 使 用 范围 ， 系 统 提 供 了 两 种 : global 全 局 使 用 ，system 只 用 于 Jenkins 和 Slave 通 信 。 
` Private Key: 输入 私 钥 ， 私 钥 的 输入 方式 有 三 种 ， 直 接 输 入 、 从 文件 获取 或 者 直接 使 用 Jenkins 服 务 器 的 私 钥 。 
` Passphrase: 设置 通关 密码 ， 如 果 不 填写 ， 则 认为 不 使 用 通关 密码 。 
. ID: 设置 Cfedentials 的 密码 ， 检 索 或 者 选择 此 Crtedentials 时 使 用 ， 可 以 显 式 指 定 ， 如 图 4-12 中 显 式 指定 为 test_ jenkins， 如 果 没 有 填写 ， 则 系统 自动 生成 一 个 UUID。 


填写 完 以 上 内 容 后 ， 点 击 OK，Credentials 就 创建 完成 ， 可 以 使 用 了 。 


[1] https:/ /jenkins.io/doc/book/managing/plugins/*? Advanced?420installation o 


4.41.5 ZEM 


Jenkins 的 应 用 场景 广泛 ， 从 仪 支持 内 联网 的 工作 站 到 连接 到 公共 互联 网 的 高 性 能 服务 器 上 都 可 以 部 署 。 为 了 更 安全 可 靠 地 支持 这 些 应 用 场景 ，Jenkins 提 供 了 安全 管理 功能 ， 放 在 jenkins 一 Manage 
Jenkins 一 Conf igure Global Security 下 面 ， 只 有 拥有 管理 员 权限 的 用 户 可 以 查看 或 者 更 改 配置 。Jenkins 提 供 的 安全 管理 配置 如 图 4-13 所 示 。 


Q Configure Global Security 


Enable security 
Disable remember me 


Access Control Secu rity Realm 


(` Delegate to servlet container 
Q Jenkins’ own user database 
() Allow users to sign up 


C LDAP 


(^ Unix user/group database 

Authorization 

( ) Anyone can do anything 

( ) Legacy mode 

Q Logged-in users can do anything 
|] Allow anonymous read access 


(C Matrix-based security 


( ) Project-based Matrix Authorization Strategy 


图 4-13 ”安全 管理 配置 


其 中 Enable Security 复 选 框 用 来 设置 是 否 启 动 安 全 管理 ， 如 果 不 启动 安全 管理 ， 所 有 用 户 (无 论 登 录 与 否 ) 都 获得 Jenkins 的 完全 控制 权 。 启 动 之 后 ，Jenkins 就 会 根据 授权 访问 策略 对 用 户 的 访问 权限 
进行 控制 。 自 2.0 版 本 之 后 ， 默 认 是 启动 的 。 下 面 着 重 介绍 Access Control 部 分 的 内 容 。 


1.Security Realm 

Security Reaml， 即 身份 认证 (Authentication) ， 配 置 用 户 的 认证 方式 ，Jenkins 默 认 支 持 以 下 几 种 认证 方式 : 

Delegate to servlet container: 委托 运行 Jenkins 的 Servlet 容 器 进行 身份 认证 ， 如 Jetty。 

: Jenkins" own user database: 使 用 Jenkins 内 建 的 用 户 数据 库 ， 自 2.0 版 本 以 后 的 默认 配置 ， 在 小 型 系统 中 推荐 使 用 。 

. LDAP: 委托 外 置 的 LDAP 服 务 器 进行 身份 认证 ， 在 较 大 的 或 者 已 经 提供 了 LDAP 认 证 的 公司 或 者 组 织 里 推荐 使 用 。 需 要 注意 的 是 ， 这 个 功能 需要 安装 LDAP plugin. 
: Unix user/group database: 委托 UNIX 操 作 系 统 级 的 用 户 数 据 库 进行 身份 验证 。 在 这 种 方式 下 ， 用 户 使 用 Jenkins 所 在 UNIX 主 机 的 用 户 名 和 密码 进行 登录 。 
2.Authorization 

即 授权 访问 ， 用 来 控制 用 户 可 以 访问 哪些 资源 ，Jenkins 默 认 支 持 如 下 授权 访问 方式 : 

- Anyone can do anything: 不 实施 任何 授权 访问 控制 ，Jenkins 的 权限 对 所 有 用 户 开放 ， 包 括 没有 登录 的 匿名 用 户 ， 建 议 仅 用 于 测试 环境 。 

Legacy mode: 被 赋予 管理 员 角 色 的 用 户 ， 获 得 Jenkins 的 所 有 控制 权限 ， 否 则 仅 有 读 权 限 ， 建 议 仅 用 于 测试 环境 。 

- Logged in users can do anything 登 录用 户 获 得 Jenkins 的 所 有 控制 权限 ， 未 登录 用 户 ， 如 果 选 中 Allow anonymous read access 则 获得 读 权 限 。 


- Mattix-based secutity 通 过 用 户 权限 管理 表 设 置 用户 或 者 用 户 组 的 访问 权限 ， 对 于 大 多 数 Jenkins 用 户 来 说 ， 此 种 授权 访问 方式 能 够 提供 足够 的 安全 控制 和 灵活 性 。 所 以 ， 没 有 其 他 特殊 要 求 的 生产 环境 ， 
可 以 使 用 此 种 方式 。 配 置 方式 如 图 4-14 所 示 。 


Q Matrix-based security 


Overall Credentials 


User/group | | | 
AdministerReadCreateDeleteManageDomainsUpdateViewManualTriggerhetriggerB 
Anonymous O 口 | 口 | 口 C O Ig O 


& jenkins | O |O 口 e 


User/group to add: | 


(© Project-based Matrix Authorization Strategy 


图 4-14  Matrix-based security 


图 4-14 中 的 列表 示 权 限 控制 项 ， 需 要 注意 的 是 ， 图 中 只 显示 了 部 分 配置 ， 实 际 中 配置 项 很 多 ， 而 且 随 着 插件 的 增多 ， 配 置 项 也 会 变 多 ， 比 如 其 中 的 Gerrit 权 限 项 就 是 由 于 安装 了 Gerrit Trigger 插 件 引 入 
的 。 图 中 的 行 配 置 了 用 户 或 者 用 户 组 的 访问 权限 。 


Oe 
在 Matrix-based security 的 模式 下 ， 用 户 权 限 是 进行 合 加 的 ， 也 就 是 说 如 果 一 个 用 户 同 时 属于 用 户 组 A、B 和 C， 那 么 这 个 用 户 的 权限 为 用 户 组 A、B、C 及 匿名 用 户 的 合集 。 


Project-based Matrix Authorization Strategy: 此 权限 控制 方式 是 Matrix-based security 的 扩展 ， 它 在 用 户 和 用 户 组 管理 的 基础 上 又 加 入 了 各 个 项 目的 访问 控制 (在 Job 页 面 进行 配 置 ) ， 比 方 说 用 户 Joe 有 项 目 


A 和 B 的 访问 权限 ,但 是 却 没有 项 目 了 D 的 访问 权限 。 具 体 配 置 使 用 方式 此 处 不 做 详细 介绍 ， 有 兴趣 的 用 户 请 自行 查阅 官方 文档 中。 
3. 用 户 管理 
Jenkins 通 过 jenkins 一 Manage Jenkins 一 Manage Users 进 行 用 户 的 增加 或 者 删除 操作 。 用 户 的 增加 和 删除 操作 很 简单 ， 此 处 不 再 说 明 。 


需要 说 明 一 点 的 是 ，Jenkins 自 1.426 版 本 开始 ， 为 RESTfu| 访 问 提 供 了 APl token 来 蔡 代 密码 进行 身份 认证 。 用 户 可 以 在 个 人 设置 页 面 查看 和 更 改 API token， 如 图 4-15 所 示 。 
Jenkins » admin 


会 People Full Name 


Q| Status - 
Description 


c Builds 


Dti Configure 
& My Views 
A Credentials 


API Token 


User ID jenkins 


API Token c67a0316863a90a76e94162103cffcb5 e 


Change API Token | 


图 4-15 API Token 


[1] https:/ /jenkins.io/doc/book /managing/secutity / ?*authorization; 


4.1.6 ”创建 Slave 


slave 可 以 是 主机 、 虚 拟 机 或 者 容器 ， 是 Jenkins 执 行 构建 Job 的 载体 ， 没 有 slave，Job 就 不 能 够 被 执行 。Jenkins 默 认为 一 个 名 为 master 的 Slave， 如 果 想 要 创建 新 的 slave， 可 以 简单 分 为 以 下 两 步 : 
1) 配置 slave。 

2) 把 Slave 挂 载 在 Jenkins 上 。 

下 面 我 们 以 创建 一 个 SSH 密 钥 访 问 型 的 Slave 为 例 来 说 明 创 建 方式 。 注 意 ， 这 种 类 型 的 Slave 需 要 安装 SSH Slave Plugin, 

1. 配 置 Slave 

Slave 的 配置 ， 简 单 来 说 就 是 安装 Java JDK 和 配置 Jenkins 信 任 的 SSH 公 钥 ， 配 置 命 令 如 代码 清单 4-2 所 示 。 


代码 清单 4-2 ”配置 Slave 


apt-get install openjdk-7-jdk 
cat id rsa.pub > -/.ssh/authorized keys 
chmod 400 -/.ssh/authorized keys 


Qua 
这 里 的 公 和 铀 id_rsa.pub 必 须 与 4.1.4 节 中 创建 的 用 于 Jenkins 和 Slave 进 行 SSH 通 信 的 安全 证 书 的 密 钥 是 一 对 。 


2. 挂 载 Slave 


在 Jenkins 页 面 上 选择 Manage Jenkins? Manage Nodes New Node， 输 入 Slave 的 名 字 ， 并 选择 类 型 为 Permanent Agent， 点 击 确认 之 后 进入 如 图 4-16 所 示 配 置 页 面 。 


Name | test label e 
Description | | © 
# of executors | 1 e 


Hemote root directory | lhome/serena/label 


Labels | unbuntu remote le 
Usage | Use this node as much as possible $0 
Launch method  ( Launch slave agents via SSH 4@ 
Host | 10.62.105.17 
Credentials (ssrena 和 © 
Host Key Verification Strategy [ Known hosts file Verification Strategy = ®© 
Availability | Keep this agent online as much as possible 
Node Properties 


(3 Environment variables 


C Tool Locations 


Save 


在 此 页 面 做 如 下 配置 : 


图 4-16” 挂 载 Slave 


: Name: Slave 的 名 字 ， 在 同一 个 Jenkins 上 ，Slave 的 名 字 必 须 是 唯一 的 。 
Hof executors: Slave 上 可 以 同时 执行 的 Job 数 目 ， 一 个 Executot 承 载 一 个 Job， 如 果 此 值 大 于 1， 则 只 有 当 所 有 的 Executot 都 消耗 完 ，Slave 的 生命 周期 才 算 结束 。 如 无 特殊 要 求 ， 此 值 一 般 默 认 设 置 为 1。 
: Remote root directory: 构建 执行 时 Slave 上 的 工作 目录 ， 在 此 设 定 下 ， 构 建 时 Slave 上 的 运行 目录 为 : SWORKSPACE- /home/serena/label/workspace/ (JOBNAME] 。 


: Labels: Slave 的 标签 。 标 签 的 作用 是 为 Slave 分 组 ， 供 Job 调 度 时 选择 Slave 用 ， 比 如 同 是 Ubuntu 系统 的 Slave 都 打上 ubuntu 标签 就 组 成 一 个 Ubuntu 组 ， 然 后 Job 配 置 的 时 候 可 以 通过 设置 ubuntu 标签 绑 定 某 些 
特定 Job 只 运行 在 安装 Ubuntu 系统 的 Slave 上 (Job 绑 定 Slave 的 方法 请 参见 4.1.7 和 4.2.4 两 节 ) 。 一 个 Slave 可 以 不 设置 标签 ， 也 可 以 设置 一 个 或 多 个 ， 多 个 标签 用 空格 隔 开 。 上 比如， 图 4-16 中 就 设置 了 ubuntu 和 


remote 两 个 标签 。 
: Usage: Slave 使 用 方式 ， 分 为 两 种 : 
* Use this node as much as possible: 默认 配置 ， 只 要 构建 可 以 使 用 这 个 Slave，Jenkins 就 会 尽量 调度 Job 到 这 个 Slave 上 。 


: Only build jobs with label expressions matching this node: 只 有 匹配 此 Slave 名 称 或 者 标签 的 Job 才 能 运行 在 这 个 Slave 上 。 这 种 模式 可 以 为 特定 Job 预 留 Slave， 比 如 为 了 性 能 测试 的 准确 性 ， 需 要 将 性 能 测试 运 
行 在 特定 的 Slave 上 ， 并 保证 一 次 只 运行 一 个 测试 ， 此 时 为 Slave 选 择 此 种 使 用 方式 ， 然 后 再 结合 labels 二 perf 和 #of executors=1 设 置 ， 就 可 以 达到 这 个 目的 。 


: Launch method: 选择 启动 方式 ， 常 用 的 有 如 下 两 种 方式 : 
Launch agent via Java Web Start: Jenkins 使 用 Java Web Statt 的 方式 启动 Slave， 如 果 Slave 是 Windows 系 统 ， 推 荐 使 用 这 种 方式 。 


: Launch slave agents via SSH: Jenkins 通 过 SSH 人 安全 链接 向 Slave 发 送 命 令 的 方式 启动 。 此 方式 需要 安装 SSH Slaves Plugin。 选 择 此 种 启动 方式 ， 还 需要 配置 如 下 两 项 : 


: Host: Slave 的 IP 地 址 或 者 主机 名 。 
: Credentials: 选择 Jenkins 和 Slave 进 行 SSH 通 信和 的 Credentials，Credentials 的 创建 请 参见 4.1.4 节 。 
由 于 本 例 中 待 创建 的 是 一 个 SSH 链 接 的 Slave， 所 以 选择 第 二 种 方式 。 


Availability: 控制 Slave 启 动 和 停止 时 间 ，Jenkins 提 供 了 三 种 方式 : 
- Keep this agent online as much as possible: 尽量 保持 Slave 处 于 在 线 状 态 。 如 果 由 于 网 络 问题 等 非 人 为 设置 造成 的 Slave 下 线 ，Jenkins 会 周期 性 地 尝试 重启 它 。 


“ake this agent online and of f line at speciftc times: Jenkins 根 据 设 定 的 启动 时 间 和 时 长 来 启动 和 停止 Slave。 如 果 Slave 在 应 该 在 线 的 时 间 下 线 了 ，Jenkins 会 周期 性 地 尝试 重启 它 。 如 果 下 线 时 间 到 ， 但 是 构 
建 Job 还 在 运行 ，Jenkins 会 在 构建 Job 结 束 后 再 停止 Slave。 


: Take this agent online when in demand, and offline when idle: 有 构建 Job 调 度 到 此 Slave 上 时 启动 Slave， 如 果 一 段 时 间 内 Slave 没 有 接 到 构建 任务 ，Jenkins 就 会 停止 Slave。 


Que 
以 上 小 节 中 说 的 周期 性 重启 尝试 和 启动 时 间 的 设置 都 基于 cton 系 统 时 间 的 指令 格式 。 


其 余 保 持 默认 配置 即 可 ， 点 击 确认 。 至 此 ， 一 个 Slave 即 创建 完成 。 可 以 到 Jenkins 一 Manage Jenkins? Manage Nodes 页 面 查看 Slave 的 状态 ， 如 图 4-17 中 master 的 状态 为 正常 可 以 使 用 ,而 
test label 为 连接 或 者 启动 失败 ， 不 能 被 调度 使 用 ， 此 时 就 需要 排查 启动 失败 原因 ， 直 到 启动 成 功 。 


Name | Architecture Clock Difference Free Disk Space Free Swap Space Free Temp Space Response Time 


Linux 


| | 7.24 GB 1024.00 MB 1.79 GB 
master (amd64) n sync 98 G 024.00 51.79 G 


üms 


Li | : 
test label MUX  Qi5min ahead 119.33 GB 63.96 GB 119.33 GB 106ms A 
(amd64) *" 


Data obtained — 1 min 19 sec 1 min 19 sec 


1 min 19 sec 1 min 19 sec 1 min 19 sec 1 min 19 sec 


Refresh status 


图 4-17” Slave 状态 


4.1.7 ”创建 Job 


Jenkins 安 装配 置 完成 之 后 ， 就 可 以 创建 Job 来 进行 自动 化 测试 和 部 署 了 。 系 统 默 认 只 支持 Freestyle 类 型 ， 如 果 想 使 用 其 他 的 Job 类 型 (如 multjob、pipeline 等 ) ， 需 要 自行 安装 相应 的 插件 。 下 面 就 
通过 创建 一 个 FreeStyle 类 型 的 Job 来 简 述 Job 创 建 流程 。 


在 Jenkins 页 面 的 左 侧面 板 中 点 击 New ltems， 在 Enter an item name 框 中 输入 test freestyle， 选 择 Freestyle Project， 然 后 点 击 OK 按 钮 ， 至 此 一 个 Job 框 架 创建 完成 。 一 个 Job 需 要 的 典型 配置 项 如 
图 4-18 所 示 。 


General Source Code Management Build Triggers Gerrit Trigger Build Environment Build 


Post-build Actions 


E448 ”典型 Job 配 置 项 


由 于 编程 语言 、 代 码 库 、 触 发 条 件 及 构建 完成 后 的 处 理 等 不 同 ， 需 要 安装 的 插件 也 会 不 同 ， 从 而 Job 的 配置 也 会 干 差 万 别 。 本 书 不 会 对 所 有 的 配置 项 都 做 详细 说 明 ， 需 要 的 用 户 可 以 根据 实际 需要 挑选 相 
关 插 件 ， 并 通过 Jenkins 页 面 提 供 的 在 线 帮 助 及 插件 的 使 用 说 明文 档 来 详细 了 解 。 下 面 仅 就 test_freestyle 用 到 的 配置 项 做 详细 介绍 ， 并 对 一 些 常用 或 者 典型 的 配置 做 简略 说 明 。 


1.General 

设置 Job 运 行 的 参数 和 属性 ， 如 图 4-19 所 示 。 
常用 的 配置 如 下 : 

: Project name: Job 名 称 。 

: Discard old builds: 构建 日 志保 存 时 长 。 

< Days to keep builds: 最 长 保存 多 少 天 的 日 志 。 


: Max# of builds to keep: 最 多 保存 多 少 条 记录 。 


| General ] Source Code Management Build Triggers Gerrit Trigger Build Environment Build Post-build Actions 


Project name test freestyle 
Description The first Job P 
[Plain text] Preview 
Discard old builds €» 
Strategy | Log Rotation $ 
Days to keep builds 30 | 
if not empty, build records are only kept up to this number of days 
Max £ of builds to keep | 100 
if not empty, only up to this number of build records are kept 
Advanced... 
(^) GitHub project 
This project is parameterized e 
2 String Parameter [2] 
Name PROJECT e 
Default Value | test jenkins | (2) 


Description project name in scm repo 


[Plain text] Preview 


A] 


C Disable this project 
[| Execute concurrent builds if necessary 


Restrict where this project can be run 


Label Expression | ubuntu 
Label ubuntu is serviced by 1 node 


| Advanced... 


图 4-19 B6 É General 
: GitHub project: 项 目的 GitHub URL. 


: This project is parameterized: Job 构 建 需 要 的 参数 ， 如 定义 构建 分 支 ， 项 目的 URL 等 。Jenkins 通 过 参数 设置 为 Job 的 构建 定义 一 个 或 者 多 个 参数 。 这 些 参数 以 键 值 对 的 方式 作为 环境 变量 传递 给 构建 脚 
本 。Jenkins 提 供 了 多 种 类 型 的 构建 参数 ， 如 表 4-1 所 示 。 


表 4-1 常用 Parameters 


Bool Parameter 定义 布尔 变量 (true/false) None 
Choice Parameter 定义 枚 举 变 量 None 
Credentials Parameter Credentials Plugin 
File Parameter 指定 上 传 文件 路 径 None 
Label 设置 执行 构建 的 Slave 标签 None 
Node 列 出 可 执行 构建 的 所 有 Slave None 


String Parameter 定义 字符 串 变 量 None 


: Disable this project: 如 果 此 配置 项 被 选 定 ， 这 个 Job 将 不 会 被 触发 。 
* Execute concurrent builds if necessary: 控制 项 目的 多 个 构建 是 否 可 以 并 行 执行 。 如 果 选 定 此 选项 ， 且 Slave 的 executots 配 置 大 于 1， 则 一 次 最 多 可 以 有 executots 个 构 建 Job 并 行 执行 


: Restrict where this project can be run: 根据 Slave 名 称 或 者 标签 ， 限 定 Job 可 执行 构建 的 Slave。 


: Block build when upstream project is building: 当 上 游 依 赖 项 目 正 在 构建 或 者 在 构建 队列 中 时 ， 阻 止 Job 触 发 新 的 构建 。 此 时 构建 任务 会 被 放 在 构建 队列 中 ， 等 所 有 依赖 项 目 都 构建 完成 ， 再 执行 构建 。 
: Block build when downstream project is building: 当下 游子 项 目 正 在 构建 或 者 在 构建 队列 中 时 ， 阻 止 Job 触 发 新 的 构建 。 此 时 构建 任务 会 被 放 在 构建 队列 中 ， 等 所 有 依赖 项 目 都 构建 完成 ， 再 执行 构建 。 
: Throttle Concurrent Builds: 设 定 项 目 最 多 可 并 行 执 行 的 构建 数目 ， 需 要 安装 Throttle Concur-rent Builds Plugin。 
: ZMQ Event Publisher: 通过 ZMQ 发 布 Job 运 行事 件 (启动 、 停 止 等 ) ， 需 要 安装 ZMQ Event Publisher. 
在 test freestyle 中 把 待 测 项 目 在 Gerrit 中 的 名 称 设置 为 PROJECT 参 数 ， 保 持 30 天 或 者 最 多 100 条 构建 记录 ， 并 限定 这 个 Job 只 能 运行 在 标签 为 ubuntu 的 Slave 上 。 
2.Source Code Management 
选择 并 配置 软件 配置 管理 工具 。 指 定 项 目的 源 代码 位 置 ， 它 将 SCM 属 性 添加 到 Job 配 置 中 ，Job 接 受 任意 数量 的 SCM 定 义 。 定 义 多 SCM 时 ， 需 要 安装 Multiple SCMs plugin, 
前 面 已 经 讲 过 Jenkins 支 持 很 多 SCM ， 每 个 SCM 的 配置 不 同 ， 在 此 我 们 不 一 一 描述 ， 用 到 时 请 自行 查阅 相关 资料 。 本 例 中 使 用 Gerrit 作 为 代码 库 ， 配 置 如 图 4-20 所 示 。 
主要 的 配置 项 说 明 如 下 : 
- Repositories: 代码 库 的 访问 配置 。Gertit 相 关 的 详细 参数 说 明 ， 请 参见 第 3 章 。 
: Repository URL: 代码 库 的 访问 链接 ， 也 即 git clone 命 令 使 用 的 链接 。 
: Credentials: 同 代码 库 链 接 的 Credentials ， 配 置 方法 参见 第 4.1.4 小 节 。 
: Name: 远 端 代 码 库 的 唯一 标识 (ID) ， 如 果 不 填写 ，Jenkins 会 自动 分 配 一 个 ， 在 git remote 命 令 中 使 用 。 
: Refspec: 本 地 引用 和 远 端 引用 的 映射 ， 在 git fetch 和 git push 命 令 中 使 用 。Gerrit Event 和 触发 方式 下 ， 此 处 必须 写 为 $GERRIT REFSPEC。 
: Branches to build: 待 构建 的 分 支 。 


Additional Behaviours: Git Plugin 是 可 扩展 的 ， 它 同志 有 插件 一 起 来 完成 SCM 配 置 。 附 加 选项 有 很 多 ， 这 里 不 一 一 说 明 ， 如 果 想 要 了 解 每 项 的 含义 和 用 途 ， 请 参阅 Jenkins 页 面 的 在 线 帮助 。 


General Source Code Management | Build Triggers Gerrit Trigger Build Environment Build 
Post-build Actions 


Source Code Management 


(^ None 
Q Git 
© 


Repositories | l mm 2:2 
Repository URL | ssh://jenkins &? http://gerrit.cibook.oz:30082/tes | € 
Credentials | jenkins (jenkins credentials wi 4| | Se Ade | 
E | Advanced... 
| Add Repository 
Branches to build EE n ES 
Branch Specifier (blank for 'any" | **/master | ®© 
. Add Branch 
Repository browser (Auto) 40 
T RS X 
dditio T 
Additional Behaviours :: Strategy for choosing what to build e 
Choosing strategy | Gerrit Trigger d 


=: Wipe out repository & force clone 


Add + 


^ Subversion €» 


图 4-20 配置 SCM 


* Strategy for choosing what to build: 本 例 配 置 Gettrit 作 为 构建 触发 代码 库 ， 必 须 选 择 Gettit Trigger. 

- Wipe out repository&force clone: 构建 开始 前 清空 工作 目录 。 

3.Build Triggers 

设置 构建 触发 条 件 。 如 前 文 所 述 ， 构 建 的 触发 条 件 有 多 种 上 且 不 是 固定 不 变 的 ，SCM 相 关 插 件 的 安装 会 引入 新 的 选项 ， 如 Gerrit Trigger Plugin 的 安装 会 引入 Gerrit Event。Jenkins 常 用 的 触发 方式 有 : 


: Trigger builds remotely: 通过 Job 的 URL 来 触发 构建 ， 为 了 安全 考虑 ， 此 触发 方式 建议 使 用 授权 token 做 认证 ， 触 发 构建 的 URL 为 JENK-INS_URL/job/JOB_NAME /build?token=TOKEN_NAME 或 


Zt / buildWithParame-ters?tokenz TOKEN. NAME 。 
- Build after other projects ate built: 在 上 游 项 目 构 建 结束 后 触发 ,根据 需要 可 设置 触发 条 件 是 上 游 项 目 构 建成 功 、 失 败 或 者 只 要 构建 结束 就 触发 ， 需 要 安装 Build-ResultTrigger Plugin. 
: Build periodically: 周期 性 触发 构建 ， 时 间 设 置 基于 cron 系 统 时 间 的 指令 格式 。 


: Poll SCM: 周期 性 轮 询 代 码 库 ， 如 果 有 代码 变更 则 触发 ， 时 间 设 置 基于 cron 系 统 时 间 的 指令 格式 。 


: GitHub hook trigger for Gl TScm polling: GitHub 代 码 库 更 新 触发 ， 需 要 安装 插件 GitHub Plugin; 
: Build when a change is pushed to GitLab: GitLab 代 码 库 更 新 触发 ， 需 要 安装 插件 GitLab Plugin。 


: Gerrit event: Gertit 代 码 库 更 新 触发 ， 需 要 安装 质 件 Gertrit Trigger Plugin。 


在 Build Triggers 选 择 Gerrit event 和 触发 之 后 就 会 进入 Gerrit Trigger 配 置 ， 如 图 4-21 所 示 。 


图 4-21 He Æ Gerrit trigger 
主要 配置 项 说 明 如 下 : 
:Choose a Server: 选择 Getrtit 服 务 ，Gertit 服 务 的 配置 方法 见 4.1.4 节 。 
` Trigger on: 设置 Gerrit 触 发 事件 ， 常 用 的 Gertit 事 件 如 表 4-2 所 示 。 


表 4-2 常用 的 Gerrit Event 


Trigger on 描述 


Change Abandoned 变更 放弃 

Change Merged 变更 合 人 

Change Restored 放弃 的 变更 恢复 
Comment Added Contains Regular Expression 评审 意见 包括 特定 表达 式 
Draft Published 草稿 发 布 

Patchset Created 变更 提交 

Ref Updated 引用 更 新 

Topic changed 主题 变更 


Gerrit Project: 设置 会 触发 构建 的 Gerrit 项 目 及 其 分 支 ， 可 以 指定 多 个 项 目 和 分 支 , 但 是 必须 指定 至 少 一 个 项 目 和 分 支 模式 。 
- Type 和 Pattern 

Plain: Gerrit 中 的 项 目 名 称 ， 大 小 写 敏感 。 

- Path: ANT X7 m Bc! 

. RegExp: 正则 表达 式 。 

本 例 中 ， 如 果 test jenkins 项 目 有 新 的 代码 提交 或 者 评审 意见 包含 recheck， 则 触发 构建 。 

4.Build Environment 

设置 构建 环境 ， 从 而 改变 构建 运行 的 方式 以 及 构建 的 输出 ， 此 设置 不 是 排他 的 ， 可 以 设置 多 个 。 


常用 的 构建 环境 设置 如 图 4-22 所 示 。 


Build Environment 


_ Delete workspace before build starts 
| | Use secret text(s) or file(s) 

|] Abort the build if it's stuck 

Add timestamps to the Console Output 


. | With Ant 


图 4-22 Ae € Build Environment 
: Delete workspace before build starts: 构建 开始 前 删除 工作 空间 ， 需 要 安装 Works-pace Cleanup Plugin. 
Use secret text (s) orftle (s) : 绑 定 安全 认证 码 。 提 供 SSH 私 钥 、 安 全 文件 及 用 户 名 密码 等 方式 ， 需 要 安装 Credentials Binding Plugin。 
* Abort the build ifit”s stuck: 如 果 构 建 被 阻塞 则 中 止 构建 ， 需 要 安装 Build timeout Plugin. 
- Add timestamps to the Console Output: 设置 构建 日 志 加 上 时 间 标 签 ， 需 要 安装 Timestampetr Plugin. 
: With Ant: 为 构建 环境 安装 并 配置 Apache Anto 
5.Build 
设置 构建 方式 ， 构 建 方式 可 以 设置 多 个 ，Jenkins 会 根据 设置 顺序 执行 。 常 用 的 构建 方式 如 下 所 示 : 


* Execute Windows batch command: 使 用 Windows 的 batch 作 为 构建 系统 。 构 建 执行 体 可 是 脚本 文件 ， 也 可 以 是 一 段 batch 命 令 ， 如 果 构 建 执行 完成 后 %ERRORLEVEL% 不 为 0， 则 被 视 为 构建 失败 。 


. Execute shell: Shell 命 令 或 者 脚本 构建 ， 如 果 脚 本 文件 没有 指明 Sha-Bangl 如 #!/bin/sh-， 则 使 用 系统 级 的 Shell 配 置 。 同 时 也 可 以 通过 Sha-Bang 指 定 用 其 他 语言 运行 脚本 ， 如 #!/ust/bin/env python 表 明 使 
用 Python 运 行 此 脚本 。 返 回 值 非 0 表 示 构 建 失败 。 


: Invoke Ant: 使 用 Ant 作 为 构建 系统 ， 返 回 值 非 0 表示 构建 失败 ， 需 要 安装 Ant Plugins 
: Invoke Gradle script: 使 用 Gradle 作 为 构建 系统 ， 返 回 值 非 0 表 示 构 建 失败 ， 需 要 安装 Gradle Plugins 
: Invoke top-level Maven targets: 使 用 Maven 作 为 构建 系统 ， 返 回 值 非 0 表示 构建 失败 ， 需 要 安装 Artifactoty Plugin。 


- Run with timeout: 规定 时 长 内 没有 完成 构建 ， 则 结束 构建 ， 需 要 安装 Build Timeout Plugin。 本 例 选 择 Execute shell 并 通过 脚本 方式 进行 构建 ， 如 图 4-23 所 示 。 


Build 


-ii Execute shell 


Command | bash ./build.sh 


See the list of available environment variables 


Add build stop ~ 


图 4-23 ”配置 Build 


build.sh 脚 本 的 内 容 如 下 : 


echo "Trigger the SPROJECT job!" 


6.Post-build Actions 
定义 构建 完成 后 的 动作 ， 构 建 完 成 之 后 可 执行 的 动作 有 很 多 ， 如 发 送 邮 件 通知 、 日 志 转 存 、 发 布 单元 测试 结果 报告 、 触 发 下 游 项 目 启动 构建 及 删除 工作 空间 等 ， 此 阶段 也 可 以 设置 多 个 。 本 例 中 仪 设置 
构建 失败 就 发 送 邮件 通知 ， 如 图 4-24 所 示 。 


Post-build Actions 


*: E-mail Notification 


Recipients | user cibook.com 


Whitespace-separated list of recipient addresses. May reference build parameters like $PARAM. E- 
mail will be sent when a build fails, becomes unstable or returns to stable. 


send e-mail for every unstable build 
[/] Send separate e-mails to individuals who broke the build 


图 4-24 配置 Post-build Actions 


7. 构 建 演 示 
上 述 配 置 完成 后 ， 点 击 按钮 Apply 一 9ave，Job 创 建成 功 ， 每 当 test_jenkins 项 目 有 新 的 代码 变更 提交 或 者 评审 中 包含 recheck， 就 会 触 帮 新 的 构建 ， 构 建 日 志 如 图 4-25 所 示 。 


同时 在 Gerrit 上 会 出 现 如 图 4-26 所 示 的 评审 过 程 记录 : 


C3 Console Output 


06:25:56 Triggered by Gerrit: http://gerrit-server-66f66896b6-x1djj:8080/7 

06:25:56 Building remotely on test label (ubuntu remote) in workspace 
/home/serena/label/workspace/test freestyle 

06:25:57 Wiping out workspace first. 

06:25:57 Cloning the remote Git repository 

06:25:57 Cloning repository ssh://jenkinségerrit.cibook.o0z2:30082/test jenkins.git 

06:25:57 > git init /home/serena/label/workspace/test freestyle £ timeout-10 

06:25:57 Fetching upstream changes from ssh://jenkins8gerrit.cibook.oz:30082/test jenkins.git 
06:25:57 > git --version £ timeout-10 

06:25:57 using GIT SSH to set credentials jenkins credentials with private key 

06:25:57 > git fetch --tags --progress ssh://jenkins8gerrit.cibook.oz:30082/test jenkins.git 
refs/heads/*:refs/remotes/origin/* # timeout-15 

06:25:57 > git config remote.origin.url ssh://jenkinségerrit.cibook.oz:30082/test jenkins.git f 
imeout-10 

06:25:57 > git config --add remote.origin.fetch -*refs/heads/*:refs/remotes/origin/* £ timeout-10 
06:25:57 > git config remote.origin.url ssh://jenkins8gerrit.cibook.oz:30082/test jenkins.git 7 
imeout-10 

06:25:57 Fetching upstream changes from ssh://jenkins8gerrit.cibook.oz:30082/test jenkins.git 
06:25:57 using GIT SSH to set credentials jenkins credentials with private key 

06:25:57 > git fetch --tags --progress ssh://jenkins8égerrit.cibook.oz:30082/test jenkins.git 
refs/changes/07/7/35 # timeout-15 

06:25:57 > git rev-parse 9b70954c984d81e0244b750c86c1695f6d61cb621^(commit) # timeout-10 
06:25:57 Checking out Revision 9b70954c98d81e0244b750c86c1695f£6d61cb621 (refs/changes/07/7/35) 
06:25:57 > git config core.sparsecheckout £ timeout-10 

06:25:57 > git checkout -f 9b70954c984d81e0244b750c86c1695f6d61cb621 £ timeout-15 

06:25:57 Commit message: "trigger build.sh" 

06:25:57 > git rev-parse FETCH HEAD^(commit) # timeout-10 

06:25:58 > git rev-list --no-walk 017d6880d224c90ef20698d0d0eb8c28be2150dc £ timeout-10 
06:25:58 [test freestyle] $ /bin/sh -xe /tmp/jenkins6643313612949672629.sh 

06:25:58 + bash ./build.sh 

06:25:58 Trigger the test jenkins job! 

06:25:58 Finished: SUCCESS 


图 4-25 构建 日 志 


Administrator Uploaded patch set 35. May 10 2:25 PM 
jenkins Patch Set 35: Build Started http://localhost:8080/job/test freestyle macro/6/ (1/3) May 10 2:25 PM 
jenkins Patch Set 35: Build Started http-//localhost:8080/job/test freestyle jjb/11/ (2/3) May 10 2:25 PM 
jenkins Patch Set 35: Build Started http://localhost:8080/job/test freestyle/74/ (3/3) May 10 2:25 PM 
jenkins Patch Set 35: Verified--1 Build Successful http://localhost:8080/job/test freestyle jijb/11/ : SUCCESS http://localhost:8080/job/test freestyle macro/6/ : ...May 10 2:25 PM 
Administrator Patch Set 34: recheck May 10 2:26 PM 


jenkins Patch Set 34: -Verified Build Started http://localhost:8080/job/test freestyle jijb/12/ (1/3) May 10 2:26 PM 
jenkins Patch Set 34: Build Started http://localhost:8080/job/test freestyle macro/7/ (2/3) May 10 2:27 PM 
jenkins Patch Set 34: Build Started http://localhost:8080/job/test freestyle/75/ (3/3) May 10 2:27 PM 
jenkins Patch Set 34: Verified--1 Build Successful http://localhost:8080/Job/test freestyle jjb/12/ : SUCCESS http//localhost:8080/job/test freestyle macro/7/ : .. May 10 2:27 PM 
jenkins Patch Set 34: -Verified Build Started http-//localhost:8080/job/test freestyle/76/ (3/3) May 10 2:27 PM 
jenkins Patch Set 34: Verified--1 Build Successful http://localhost:8080/Job/test freestyle jjb/12/ : SUCCESS http-/localhost:8080/job/test freestyle macro/7/ : .. May 10 2:27 PM 


图 4-26 ”Gertit 构 建 记录 


从 图 4-26 中 可 以 看 出 ， 每 次 有 新 的 PatchSet 提 交 或 者 评审 中 包含 recheck 都 会 触发 test_freestyle 构 建 ， 构 建 过 程 中 Jenkins 会 发 送 两 条 消息 给 Gerrit， 一 条 表示 构建 开始 ， 即 评审 中 包含 Build Started 那 
条 ， 第 二 条 表示 构建 结束 并 进行 投票 ， 即 评审 中 包含 Verif ied+1 那 条 ， 如 果 构 建 失败 则 会 返回 Verif ied-1 信 息 。 


管理 、 不 可 追溯 和 配置 不 可 复 用 等 问题 ， 为 了 解决 这 些 问题 OpenStack Infra 团 队 开 发 了 组 件 Jenkins-job-builder 来 对 这 些 Job 进 行 代 码 化 自动 化 管理 ， 我 们 将 在 下 一 章 介 绍 。 


[1] https://ant.apache.org/manual/dirtasks.html o 


[2] https://en.wikipedia.org/wiki/Shebang_ (Unix) 。 


4.2 Jenkins Job Builder 


Jenkins 创 建 的 Job 以 XML 文件 的 格式 保存 在 $JENKINS HOME/jobs/{job_name}/conf ig.xml 中 。XML 文 件 不 易于 阅读 和 维护 ， 因 此 Jenkins Job Builder (简称 JB) 采用 易于 阅读 的 YAML 或 者 JSON 
格式 来 配置 Job， 然 后 转化 为 Jenkins 易 于 理解 的 XML 文件 ， 更 新 到 Jenkins 中 。YAML 和 JSON 都 可 以 用 来 定义 JB Job， 且 它们 之 间 是 可 以 相互 转换 的 ， 由 于 YAML 使 用 更 加 广泛 ， 所 以 本 书 只 介绍 YAML 文 
件 的 使 用 方式 。 


4.2.1 ZJB 


山 B 是 使 用 Python 开发 的 开源 软件 ， 和 其 他 所 有 Python 包 一 样 都 支持 PIP 开 发 包 安 装 和 源码 安装 。PIP 安 装 如 下 所 示 : 


pip install jenkins-job-builder 


安装 成 功 之 后 ， 就 能 够 使 用 enkins-jobs 这 个 命令 来 测试 YAML 文 件 或 者 创建 更 新 Job 了 。 


4.2.2 配置 JJB 


山 B 默 认 会 按 顺 序 从 以 下 代码 所 描述 的 位 置 找 配置 文件 : 


1. ~/.config/jenkins jobs/jenkins jobs.ini 
2. «script directory»/jenkins jobs.ini 
3. /etc/jenkins jobs/jenkins jobs.ini 


当然 也 支持 自 定义 路 径 ， 在 命令 行 中 使 用 --conf jenkins jobs.ini 参 数 即 可 。 配 置 文 件 中 指定 Jenkins 的 URL 地 址 和 登录 信息 ， 从 而 人 JB 可 以 将 Job 更 新 到 指定 的 Jenkins。 简 单 的 配置 信息 如 代码 清单 4-3 
所 示 。 


代码 清单 4-3 jenkins jobs.ini 


[job builder] 
ignore cache-True 
recursive-False 


[jenkins] 

user-jenkins 

password-jenkins 
url-http://jenkins.cibook.oz:8080/jenkins 


4.2.3 ”使 用 JJB 
定义 Job 的 YAML 文 件 编写 完成 之 后 ， 进 行 Job 的 上 传 之 前 ， 可 以 通过 jenkins-jobs 命 令 来 验证 配置 格式 和 内 容 是 否 正确 ， 验 证 成 功 之 后 就 可 以 把 Job 创 建 或 者 更 新 到 Jenkins 上 了 。 


1.Job 定 义 验证 


Job 定 义 通过 test 命 令 来 进行 验证 ， 如 下 面 代码 所 示 : 


jenkins-jobs test yaml path/foo.yaml # 验证 Job 定义 ， 并 将 结果 打印 到 控制 台 
jenkins-jobs test yaml path/foo.yaml -o xml path # 验证 Job 定义 ， 并 将 结果 保存 到 目录 xml path 


2. 创 建 和 更 新 Job 


update 命 令 用 来 创建 或 者 更 新 job， 如 下 面 代 码 所 示 : 


jenkins-jobs update yaml path/foo.yaml # 创建 或 更 新  yaml path 目录 下 foo Job 
jenkins-jobs update yaml path/ t 创建 或 更 新 yam] path 目录 下 所 有 Job 
jenkins-jobs update yaml path/ foo bar # 创建 或 更 新 yaml path 目录 下 foo 和 bar Job 


3. 删 除 Job 


Job 的 删除 通过 delete 或 者 delete-all 命 令 进行 ， 如 下 面 代码 所 示 : 


jenkins-jobs delete foo # WW 除 foo Job 
jenkins-jobs delete-all # 删除 Jenkins 上 所 有 Job 


424 ”JJB 语 法 详解 

JB 通 过 一 系列 自 定 义 的 语义 来 描述 Job， 可 以 在 一 个 YAML 文 件 里 完成 所 有 Project 或 者 Job 定 义 ， 也 可 以 是 多 个 YAML 文 件 来 实现 JB Job 管 理 。 在 进行 XML 文 件 转 换 时 ， 可 以 指定 单个 YAML 文 件 , 也 
可 选择 存放 目录 。 

1Job 

在 几 B 中 ，Job 通 过 一 些 通用 参数 和 模块 进行 描述 ，Job 定 义 的 模块 有 很 多 ， 在 此 不 一 一 介绍 ， 有 需要 的 读者 可 自行 查阅 官方 文档 [1]， 其 常用 的 模块 及 执行 顺序 如 下 : 
1) Parameters/Properties 
2) SCM 
3) Triggers 


4) Wrappers 


5) Builders 


6) Publishers 
手动 创建 的 test freestyle 的 完整 Job 定 义 如 代码 清单 4-4 所 示 。 


代码 清单 4-4 test jenkins.yaml 


- job: 
name: test freestyle 
project type: freestyle 
disabled: false 
node: ubuntu 
parameters: 
- string: 
name: PROJECT default: test jenkins 
description: 
project name in scm repo 
properties: 
- build-discarder: 
days-to-keep: 30 
num-to-keep: 100 


scm: 
- git: 
credentials-id: 'jenkins-ci' 
url: 'ssh://jenkinsGgerrit.cibook.oz:30082/test jenkins.git' 
branches: 

- "'**/master' 

choosing-strategy: 'gerrit' 

refspec: 'SGERRIT REFSPEC' 

Skip-tag: 'true' 

wipe-workspace: 'true' 

triggers: 
- gerrit: 
server-name: 'gerrit' 
trigger-on: 

- patchset-created-event: 
exclude-drafts: 'false' 
exclude-trivial-rebase: 'false' 
exclude-no-code-change: 'false' 

- draft-published-event 

- comment-added-contains-event: 
comment-contains-value: 'recheck' 

projects: 

- project-compare-type: 'ANT' 
project-pattern: 'test jenkins' 
branches: 

- branch-compare-type: 'ANT' 
branch-pattern: '**/master' 
wrappers: 
- timestamps 
builders: 
- shell: 'bash build.sh' 
publishers: 
- email: 


recipients: user(cibook.com 
notify-every-unstable-build: True 
send-to-individuals: true 


下 面 就 代码 清单 4-4 的 各 个 模块 分 别 进行 介绍 。 


一 组 简单 的 字符 串 或 者 布尔 值 的 键 值 对 ， 对 应 4.1.7 节 中 的 部 分 配置 如 下 : 
: name: Job 名 称 ， 对 应 Job 配 置 页 面 上 定义 的 Project name。 
.btoject-type: Job 类 型 ， 黑 认为 ffeestyle 类 型 ， 对 应 手动 创建 Job 时 选择 的 Job 类 型 。 
: disabled: 布尔 值 ， 如 果 设 置 为 ttue， 则 此 Job 不 会 被 触发 。 默 认为 flse， 对 应 Job 配 置 页 面 上 定义 的 Disable this project. 
: concurrent: 布尔 值 ， 设 置 此 Job 的 多 个 构建 是 否 可 以 并 行 执行 ， 默 认为 false， 对 应 Job 配 置 页 面 上 定义 的 Execute concurrent builds if necessary。 
: node: 通过 Slave 名 称 或 者 标签 ， 绑 定 Job 运 行 在 哪些 Slave 上 ， 对 应 Job 配 置 页 面 上 定义 的 Resttict where this project can be runs 
上 面 手 动 创建 的 test_ freestyle Job 中 通用 参数 部 分 的 描述 如 代码 清单 4-5 所 示 。 


代码 清单 4-5 general parameters.yaml 


- job: 
name: test freestyle 
project type: freestyle 
disabled: false 
node: ubuntu 


3.Parameters 
JJB 通 过 Parameters 对 应 第 4.1.7 小 节 中 This project is parameterized 的 参数 定义 ， 如 表 4-3 所 示 。 


表 4-3 JJB 中 常用 的 Parameters 


Parameters 功能 Job 配置 


bool 定义 布尔 变量 (true/false) Bool Parameter 
choice 定义 枚 举 变量 Choice Parameter 


credentials 选择 credentials Credentials Parameter 
file 指定 上 传 文件 路 径 File Parameter 

label 设置 执行 构建 的 Slave 标签 Label 

node 列 出 可 执行 构建 的 所 有 Slave Node 


string 定义 字符 串 变 量 String Parameter 


如 在 test_freestyle 中 定义 的 参数 $PROJECT， 在 人 JB 中 可 以 进行 如 代码 清单 4-6 所 示 的 描述 。 


代码 清单 4-6 project parameter.yaml 


parameters: 
- string: 
name: PROJECT 
default: test jenkins 
description: "project name in scm repo" 


再 如 ， 绑 定 test freestyle 到 安装 Ubuntu 系统 的 Slave 上 执行 也 可 以 通过 定义 label 参 数 实现 ， 如 代码 清单 4-7 所 示 。 


代码 清单 4-7 label parameter.yaml 


parameters: 
- label: 
name: test label 
default: ubuntu 
description: "Run this job on test label Slave." 


Qu 

如 果 Job 中 同时 设 定 了 label 参 数 和 上 一 节 中 的 node 参 数 ， 则 label 起 决定 作用 。 

4.Properties 

JJB 通 过 Properties 描 述 Job 的 属性 配置 ， 对 应 4.1.7 节 中 属性 配置 部 分 的 人 JB 描述 如 表 4-4 所 示 。 


表 4-4 JJB 中 常用 的 Propetties 


Proper-ties Job 配置 
build-blocker 控制 Job 顺序 执行 Block p when upstream pee! is TROIS 
Block build when downstream project is building 
build-discarder 构建 日 志保 持 时 长 配置 Discard old builds 
github mi HÆ GitHub 上 的 URL GitHub project 
throttle 可 执行 的 并 行 构建 数目 Throttle Concurrent Builds 


zeromq-event 通过 ZMQ 发 布 Job 事件 ZMQ Event Publisher 


test freestyle 中 构建 日 志保 存 时 长 的 定义 在 JB 中 的 描述 如 代码 清单 4-8 所 示 。 
代码 清单 4-8 properties.yaml 


properties: 
- build-discarder: 
days-to-keep: 30 
num-to-keep: 100 


5.SCM 


SCM 模 块 对 应 Job 配 置 中 的 Source Code Management， 正 如 4.1.7 节 中 讲 到 的 ，Jenkins 支 持 的 SCM 很 多 ， 每 个 配置 都 不 一 样 ， 在 此 不 一 一 说 明 ， 此 处 仅 根 据 test freestyle 的 SCM 配 置 来 简单 说 明 一 
下 JJB 的 SCM 描 述 方法 。 图 4-20 配 置 的 JJB 描 述 如 代码 清单 4-9 所 示 。 


代码 清单 4-9 gerrit scm.yaml 


scm: 
=L 
credentials-id: jenkins-ci 
url: ssh://jenkins@gerrit.cibook.oz:30082/test jenkins.git 
branches: 
- '**/master' 
choosing-strategy: 'gerrit' 
refspec: 'SGERRIT REFSPEC' 
wipe-workspace: 'true' 


代码 清单 4-9 中 的 参数 说 明 如 下 : 
| git: 指明 代码 库 是 Git 类 型 。 
: credentials-id: 在 4.1.4 节 中 创建 的 访问 代码 库 的 Credentials， 对 应 Job 配 置 中 的 Creden-tials。 
urn: 代码 库 的 访问 链接 ， 对 应 Job 配 置 中 的 Repositoty URL. 
. branches: 待 构建 的 分 支 ， 对 应 Job 配 置 中 的 Branches to build。 
choosing-strategy: 配置 Gertit 作 为 SCM 时 必须 配置 ， 对 应 Job 配 置 中 的 Choosing strategy，gettit 对 应 选择 项 Gertit Trigget。 
.tefspec: 本 地 引用 和 远 端 引用 的 映射 ， 对 应 Job 配 置 中 的 Refspec。 
wipe-wotkspace: 构建 开始 前 删除 工作 空间 ， 对 应 Job 配 置 中 的 Wipe out repository&force clone. 
6.Triggers 


Triggers 对 应 4.1.7 节 ， 常 用 的 如 表 4-5 所 示 。 


表 4-5 JJB 中 常用 的 Triggers 


Triggers 


timed 周期 触发 


Job 配置 
Build periodically 


Poll SCM 


pollscm 
build-result 其 他 Job 构建 结束 


test freestyle 中 的 Gerrit 库 代码 变更 触发 的 定义 如 代码 清单 4-10 所 示 。 


Build after other projects are built 

Gerrit event 

GitHub hook trigger for GITScm polling 
Build when a change is pushed to GitLab 


代码 清单 4-10 gerrit trigger.yaml 


triggers: 
- gerrit: 
server-name: 'gerrit' 
trigger-on: 
- patchset-created-event: 
exclude-drafts: 'false' 


exclude-trivial-rebase: 'false' 
exclude-no-code-change: 'false' 
- draft-published-event 


- comment-added-contains-event: 
comment-contains-value: 'recheck' 


projects: 

- project-compare-type: 'ANT' 
project-pattern: 'test jenkins' 
branches: 

- branch-compare-type: 'ANT' 


yp 
branch-pattern: '**/master' 
代码 清单 4-10 参 数 说 明 如 下 : 
- setver-name: Gettit 服 务 的 名 字 ， 对 应 Job 配 置 Choose a Server. 
.ttigget-on: 设置 Gettit 触 发 事件 ， 对 应 Job 配 置 Trigeet on， 表 4-2 中 的 Gettit 触 发 事件 在 JJB 中 的 定义 如 表 4-6 所 示 。 


表 4-6 JB 中 常用 的 Gerrit Events 


Trigger on 描述 Job 配置 
change-abandoned-event Change Abandoned 


change-merged-event 


change-restored-event 


comment-added-contains-event 


draft-published-event 
patchset-created-event 


ref-updated-event 


变更 合 人 
放弃 的 变更 恢复 


Change Merged 
Change Restored 


评审 意见 包括 特定 表达 式 


Comment Added Contains ... 


: projects: Gettit 项 目 和 分 支 描述 ， 对 应 于 Job 配 置 的 Gettit Ptoject， 其 匹配 类 型 和 Job 配 置 的 对 应 关系 如 表 4-7 所 示 。 


JJB fxh 
ANT 
PLAIN 
REG EXP 


7. Wrappers 


对 应 4.1.7 节 ， 常 用 Wrappers 的 人 JB 描述 如 表 4-8 所 示 。 


草稿 发 布 Draft Published 
变更 提交 Patchset Created 
引用 更 新 Ref Updated 
表 4-7 Patterns 对 应 关系 
Job 配置 匹配 规则 


Apache ANT 匹配 
项 目 名 完全 匹配 


正则 表达 式 匹 配 


表 4-8 J]JB 中 常用 的 Wrappets 


Wrappers 
credentials-binding 绑 定 Credentials 
timeout 设置 构建 超时 时 长 


buildstamps 设置 打印 日 志 加 时 间 玲 
Wworkspace-cleanup 构建 前 清理 工作 空间 


为 test freestyle 的 输出 日 志 加 时 间 信 息 的 描述 如 代码 清单 4-11 所 示 。 


代码 清单 4-11 timestamps wrapper.yaml 


wrappers: 
- timestamps: 


Job 配置 
Use secret text (s)or file (s) 
Abort the build if it" s stuck 
Add timestamps to the Console Output 


Delete workspace before build starts 


8.Builders 


对 应 4.1.7 节 ， 常 用 Builders 的 JJB 描 述 如 表 4-9 所 示 。 


表 4-9 JJB 中 常用 的 Buildets 


Builders 
batch 执行 Python 命令 或 脚本 

Builders IJA 
shell 执行 Shell 命令 或 脚本 
ant 执行 ANT 任务 


gradle 执行 Gradle 任务 
maven-target 执行 top-level Maven 任务 


test freestyle 的 构建 执行 如 代码 清单 4-12 所 示 。 


代码 清单 4-12 shell builder.yaml 


Job 配置 


Execute Windows batch command 


( 续 ) 


-— 


Job 配置 
Execute shell 
Invoke Ant 
Invoke Gradle script 


Invoke top-level Maven targets 


builders: 
- shell: 'bash build.sh' 


一 次 构建 执行 可 以 触发 多 个 动作 ， 这 些 动作 可 以 不 相同 。 如 代码 清单 4-13 所 示 ， 一 次 Job 触 发 了 两 个 动作 ， 一 个 编译 docker 容 器 ， 一 个 打印 任务 执行 完成 。 


代码 清单 4-13 multi buiders.yaml 


builders: 

- docker-build-publish: 
repo-name: 'test' 
repo-tag: 'test-tag' 
no-cache: true 
no-force-pull: false 
Skip-build: false 
Skip-decorate: false 
Skip-latest: false 
Skip-tag: false 

file-path: '/tmp/' 

build-context: '/tmp/' 

- shell: 
'echo docker build finish' 


9.Publishers 
Publishers 定 义 了 Job 构 建 完成 后 的 发 布 工作 ， 常 用 的 Publishers 如 表 4-10 所 示 。 


表 4-10 JJB 中 常用 的 Publishers 


Builders 
cobertura 产生 代码 履 盖 率 报 告 
email 
github-notifier 


junit 发 布 JUnit 测试 结果 
postbuildscript 定义 构建 完成 后 的 脚本 操作 


scp 通过 SCP 上 传 文件 


workspace-cleanup 构建 完成 后 清理 工作 空间 


Job 配置 
Publish Cobertura Coverage Report 
E-mail Notification 
Set GitHub commit status 
Publish JUnit test result report 
Post Build task 
Publish artifacts to SCP Repository 


Delete workspace when build is done 


构建 失败 则 发 送 邮件 通知 的 定义 如 代码 清单 4-14 所 示 。 


代码 清单 4-14 email publish.yaml 


publishers: 
- email: 


recipients: user(8cibook.com 
notify-every-unstable-build: True 


send-to-individuals: 


10.Job Template 


如 果 一 个 项 目 中 多 个 Job 功 能 相同 ， 只 是 名 称 、 版 本 、 分 支 等 有 区 别 ， 或 者 多 个 项 目 需要 执行 相同 或 类 似 的 构建 job， 这 样 的 情况 下 就 要 考虑 使 用 Job Template 来 定义 Job， 在 定义 Project 的 时 候 通 过 变 
量 置换 来 实例 化 Job， 以 增加 代码 的 重用 性 ， 减 少 维护 的 工作 量 。Job Template 的 语义 和 Job 的 语义 相同 ， 只 是 在 定义 中 增加 了 变量 。 例 如 ， 如 果 多 个 项 目 都 通过 Shell 方 式 构建 ， 且 其 中 test jenkins 项 目 有 
master 和 stable 两 个 分 支 ， 且 两 个 分 支 都 需 


true 


进行 代码 变更 构建 检查 ， 可 通过 代码 清单 4-15 的 内 容 来 进行 描述 。 


代码 清单 4-15 job template.yaml 


- job-template: 


name: 'test fr 
builders: 
- shell: 


在 这 种 描述 下 ，{pnamel 和 {stream} 参 数 需要 通过 Project 的 参数 定义 进行 实例 化 ，Project 的 定义 请 参见 4.2.4 节 。 


11.Job Group 


如 果 一 组 Job 总 是 在 一 起 使 用 ， 则 可 以 定义 一 个 Job Group。 如 OpenStack 社 区 大 部 分 项 目 都 是 用 Python 编 码 和 RST 写 文档 ，pylint 检 查 和 RST 格 式 检查 就 可 以 组 织 为 一 个 Job Group， 如 代码 清单 4-16 
所 示 。 


style-{pname}-{stream}' 


'bash build.sh' 


代码 清单 4-16 job group.yaml 


- job-group: 
name : 
jobs: 


12.Project 


Project 的 使 用 是 为 了 把 相关 的 Job 集 中 在 一 起 ， 并 为 Job Template 提 供 实例 化 参数 ， 如 代码 清单 4-15 中 的 Job Template 可 以 通过 代码 清单 4-17 所 示 的 Project 描 述 进行 实例 化 。 


' (pname] -lint-check' 


代码 清单 4-17 project.yaml 


- project: 


name: test jenkins project 
pname: test jenkins 


stream: 


' {pname} -pylint-check' 
' (pname] -rst-check' 


- master 
- stable 
jobs: 


'test-freestyle-(pname]-(stream)' 


在 这 种 描述 下 ，JJB 解 析 的 时 候 ，{pname} 参 数 实例 化 为 test_jenkins，{stream} 参 数 通过 master 和 stable 分 别 进行 两 次 实例 化 ， 因 此 在 Jenkins 中 会 增加 test-freestyle-test jenkins-master 和 test- 


13.Macros 


freestyle-test jenkins-stable 两 个 Job。 


山 B 通 过 宏 扩 展 的 方式 管理 复杂 或 重复 的 Job 动 作 ， 宏 定义 的 格式 分 为 定义 宏 应 用 的 模块 ， 定 义 宏 名 和 定义 安定 义 体 三 部 分 ， 例 如 test_freestyle 中 参数 PROJECT 的 安定 义 如 代码 清单 4-18 所 示 。 


代码 清单 4-18 macro parameter.yaml 


# 定义 宏 应 


- parameter: 


j 模 块 ， 指 


明 此 处 是 ”Parameters 模块 宏 定 义 


# 定义 宏 定义 名 称 为 ”project-parameters 
name: project-parameters 


# 定义 宏 定义 体 

parameters: 
- string: 
name: 


default: 
description: 


PROJECT 
test jenkins 
Define job type 


宏 定义 完成 之 后 ， 就 可 以 在 Job 中 进行 引用 了 ， 如 代码 清单 4-19 所 示 。 


代码 清单 4-19 macro_parameter reference.yaml 


- job: 


freestyle 


name: test 
# 宏 引 用 ， 


parameters: 


引用 宏 定义 project-parameters 


- project-parameters: 


在 人 JB 解 析 的 时 人 息 ， 宏 引用 会 被 替换 为 宏 定 义 体 ， 如 代码 清单 4-20 所 示 。 


代码 清单 4-20 macro extension.yaml 


: test 


freestyle 


+ 宏 扩 展 部 分 ， 以 下 是 通过 project-parameters 的 宏 定义 体 进行 的 宏 扩展 ， 


parameters: 


此 可 以 看 出 它 是 宏 定 义 体 的 纯粹 的 复制 和 粘贴 


- string: 

name: PROJECT 

default: test jenkins 
description: Define job type 


通过 以 上 描述 ， 使 用 宏 定 义 和 Project 定 义 重 构 test freestyle 中 的 核心 Parameter、SCM 和 Triggers 部 分 ， 使 其 适用 于 不 同 的 项 目 ， 如 代码 清单 4-21 所 示 。 


代码 清单 4-21 macros.yaml 


- parameter: 
name: project-parameters 
parameters: 
- string: 
name: PROJECT 
default: 'íproject]' 
description: Define job type 


- sem: 
name: gerrit-scm scm: 
= cos 
credentials-id: jenkins-ci 
url: 'ssh://jenkinsQGgerrit.cibook.oz:30082/SPROJECT.git' 
branches: 
'** /master' 
choosing-strategy: 'gerrit' 
refspec: 'SGERRIT REFSPEC' 
Skip-tag: 'true' 
wipe-workspace: 'true' 


- trigger: 
name: patchset created trigger 
triggers: 
= gerrit: 
server-name: 'gerrit' 
trigger-on: 

- patchset-created-event: 
exclude-drafts: 'false' 
exclude-trivial-rebase:'false' 
exclude-no-code-change: 'false' 

- draft-published-event 

- comment-added-contains-event: 

comment-contains-value: 'recheck' 


projects: 
- project-compare-type: 'ANT' 
project-pattern: 'íproject]' 
branches: 
- branch-compare-type: 'ANT' 
branch-pattern: '**/master' 


其 引用 方式 如 代码 清单 4-22 所 示 。 


代码 清单 4-22 test jenkins macro.yaml 


- job-template: 
name: 'test freestyle-(pname]' 
project type: freestyle 
disabled: false 
parameters: 
- project-parameters: 
project: 'ípname]' 


scm: 
- gerrit-scm 
triggers: 
- patchset created trigger: 
project: 'ípname]' 


- project: 
name: test jenkins 
pname: test jenkins 
jobs: 
- ''test freestyle-(pname]' 


14.Defaults 


集中 收集 Job 的 一 些 默 认 属 性 和 动作 ， 在 创建 Job 时 提供 这 些 值 ， 当 然 ， 在 Job 定 义 中 也 可 以 重 置 这 些 默认 属性 。 如 果 使 用 global 指 定 了 一 组 默认 值 ， 则 在 所 有 Job (和 Job Template) 中 都 可 以 使 用 ， 
除非 在 Job 中 进行 了 重 置 。 简 单 的 Defaults 的 例子 如 代码 清单 4-23 所 示 。 


代码 清单 4-23 defaults.yaml 


- defaults: 
name: global 
arch: 'i386' 
job-template: 
name: 'build-[arch)' 
builders: 
- shell: "echo Build arch {arch}." 
- project: 
name: projectl 
jobs: 
- 'build-[arch]' 
- project: 
name: project2 
jobs: 
= 'build-[(arch]': 
arch: 'amd64' 


通过 上 面 的 JB 描 述 ，project1 中 的 arch 使 用 全 局 默认 值 ， 因 此 将 运行 build-i386， 而 project2 由 于 对 arch 进 行 了 重 置 ， 运 行 build-amd64。 


[1] https://docs.openstack.org/infra/jenkins-job-builder/ 。 


4.3 Python Jenkins 


上 文 我 们 提 到 过 Nodepool 是 通过 HTTP 给 Jenkins 发 送 消息 的 ，OpenStack 社 区 开发 了 python-jenkins 组 件 来 实现 这 些 HTTP 消 息 的 发 送 和 接收 。 


4.3.1 安装 python-jenkins 


python-jenkins 支 持 PIP 开 发 包 安 装 和 源码 安装 。PIP 安 装 如 下 所 示 : 


pip install python-jenkins 


4.3.2 f&FBpython-jenkins 


python-jenkins 库 提供 了 一 种 使 用 RESTful API 管 理 Jenkins 服 务 的 方法 ， 它 提供 的 服务 主要 包括 : 

. 版 本 管理 : 获取 Jenkins 运 行 版 本 。 

.Job 管理 : Job 管 理 主要 包括 创建 、 配 置 、 更 新 、 删 除 Job， 获 取 Job 的 构建 状态 、 构 建 日 志和 构建 结果 ， 忆 动 或 者 取消 Job 构 建 等 。 

“ 播 件 管理 : 主要 是 安装 或 者 卸载 插件 。 

 Slave/£ 322: 创建 、 删 除 或 者 配置 Slave。 

python-jenkins 的 调用 方式 大 致 相同 ， 下 面 我 们 仅 以 获取 Jenkins 的 运行 版 本 为 例 (如 代码 清单 4-24) 说 明 其 调用 方式 ， 详 细 的 接口 说 明 请 参见 官方 文档 站。 


代码 清单 4-24 ”python-jenkins 应 用 举例 


import jenkins 


server = jenkins.Jenkins (url-'http://jenkins.cibook.oz:8080', 
username-'user', 

password-'pass', 

timeout-10) # 实例 化 Jenkins 通信 和 句柄 
version = server.get version() + 获取 Jenkins 服务 的 运行 版 本 
print('Hello Jenkins {} .format (version)) 


[1] http:/ /python-jenkins.readthedocs.io/en/latest/ o 


44 本章 小 结 


本 章 通 过 Gerrit+Jenkins 的 方式 对 典型 的 持续 集成 系统 进行 了 系统 介绍 ， 并 通过 一 个 简单 但 是 经 典 的 test_freestyle Job 对 Jenkins 上 Job 的 配置 及 配套 组 件 JB 的 使 用 做 了 较为 全 面 的 介绍 。 


第 5 章 ” 门 控 系统 (Zuul) 


本 章 将 详细 说 明 Zuul[1 组 件 ， 它 是 Openstack 社 区 的 一 个 基础 设施 项 目 ， 致 力 于 实现 项 目 及 关联 项 目 之 间 的 守护 者 ， 仅 当 与 变更 相关 的 所 有 测试 都 通过 后 ， 它 才 会 将 变更 合 入 到 相应 的 目标 分 支 。 实 现 
这 种 机 制 的 系统 称 之 为 门 控 (gating) 系统 。 


本 章 涉 及 大 量 的 Git 和 Gerrit 系 统 的 术语 和 操作 ， 阅 读 到 本 章节 时 默认 您 已 经 阅读 了 第 3 章 的 内 容 ， 如 果 您 不 熟悉 ， 可 以 在 任何 时 候 回 到 第 3 章 进行 了 解 。 


目前 ， 大 部 分 软件 开发 项 目 都 是 由 开发 人 员 负 责 把 代码 合 入 到 主线 分 支 ， 然 后 对 这 个 变更 进行 回归 测试 ， 如 果 引 入 了 故障 ， 再 通过 一 系列 的 补丁 来 修复 。 在 此 过 程 中 ， 回 归 测试 可 以 通过 Cl 来 自动 化 运 
行 。 一 旦 主线 分 支 被 破坏 ， 对 开发 人 员 而 言 将 是 一 件 非 常 令 人 泪 形 的 事 ， 这 将 导致 其 他 的 提交 无 法 得 到 及 时 验证 ， 从 而 降低 整个 团队 的 效率 ， 在 开发 人 员 比 较 多 或 者 提交 频率 比较 高 的 项 目 中 尤其 明显 ，。 


为 此 ， 许 多 项 目 可 能 要 求 开 友人 员 在 合 入 代码 前 进行 测试 以 保证 代码 不 产生 恶化， 这 是 一 种 非 正式 的 、 通 过 人 为 来 保证 的 门 控 系统 ， 随 着 更 多 的 开发 人 员 加 入 ， 变 更 越 来 越 频 繁 ， 测 试 任务 越 来 越 复 
杂 ， 这 种 方式 水 平 扩 展 能 力 受 限 ， 因 而 无 法 保证 开发 人 员 的 开发 效率 。Zuul 的 门 控 系 统 机 制 正 是 着 眼 于 帮助 项 目 和 开发 人 员 解 决 该 困境 。 采 用 Zuul， 就 可 以 对 这 些 测试 工作 进行 自动 化 编排 ， 并 确保 即使 有 
大 量 的 变更 也 能 得 到 正确 的 并 行 处 理 。 


Zuul 保 证 主线 分 支 对 所 有 开发 人 员 开 放 ， 所 有 工作 都 可 以 基于 主线 进行 开发 。 一 个 变更 只 有 通过 所 有 回归 测试 才 会 被 合并 到 主线 ， 避 免 主线 由 于 合 入 补丁 而 可 能 产生 的 恶化 。 
你 可 能 会 有 疑问 ， 使 用 Gerrit+Jenkins+ 守 护 任 务 的 组 合 ， 是 不 是 也 能 完成 Zuu| 的 这 种 门 控 系统 的 功能 ， 通 过 本 章 的 学 习 ， 你 能 了 解 这 其 中 的 差别 。 

Og 

社区 最 新 发 布 的 OpenStack Zuul 文 档 是 基于 Zuul V3 的 ， 本 章 如 不 特别 说 明 ，Zuul 都 是 指 Zuul V2 版 本 ， 需 要 通过 检 出 Zuul VAARA AT RAE, UTARA, 


[1] https://docs.openstack.org/infra/zuul/。 


[2] http://git.openstack.org/cgit/openstack-infra/zuul/tree/doc/soutce?h=2.6.0。 


5.1 Zuu| 组 件 介绍 


Zuu| 是 由 若干 组 件 组 成 的 一 个 分 布 式 系统 ， 如 图 5-1 所 示 。 


Zuul 组 件 


Zuul Cloner 


http based 
git repo 


Zuul Client 


I 
Gearman | 


一 一 天 一 一 一 一 一 了 


QT ML di ~ 
|^ Jenkins ; | Nodepool ; 


图 5-1 Zuul 组 件 及 外 部 关系 
Zuul 各 组 件 的 说 明 如 下 : 
: Zuul Server: 守护 进程 ， 与 Gertit 和 Jenkins 等 外 部 模块 通信 ; 负责 从 Gerttit 接 收 事件 ， 通 知 Jenkins 启 动 任务 ， 并 从 Jenkins 收 集结 果 ， 在 任务 运行 结束 后 把 结果 上 报到 Gettit 服 务 器 。 
: Zuul Merger: 为 测试 任务 准备 Git 库 ， 这 要 求 为 它 提供 一 个 Web 服 务 器 ， 以 满足 测试 任务 可 基于 http 进 行 Git 克 隆 操 作 。 
Zuul Cloner: 这 是 一 个 命令 行 工具 ， 它 用 于 设置 测试 任务 的 工作 目录 (workspace) ， 并 从 Zuul Metger 准 备 好 的 Git 库 中 进行 克隆 操作 。 
- Zuul Client: 这 是 Zuul 的 简单 的 命令 行 客户 端 ， 可 以 用 来 修改 Zuul 的 行为 ， 比 如 : 添加 /删除 队列 中 的 元 素 ， 调 整 队列 中 元 素 的 次 序 。 
: Gearman: 可 选 的 内 置 Gearman 服 务 器 。 


当 Zuul 收 到 Gerrit 触 发 事件 时 ， 这 些 组 件 的 协作 流程 如 图 5-2 所 示 。 


l.Change notification 


一 一 一 一 2.Match 上 and enqueue 


— — — —7 |3.Fetch head event from queue 


4.Prepare Git repo 
branch head + 
current change 


"EN 5.Clone and merge : 


6.Inform Git 
repo ready 


7.Notify jobs 


in jenkins 


— —] |8.Choose jenkins Slave(s) 


| |9.Clone from Zuul and execute 


10.Report jobs status 


l1 l.Report status vote 
(if permitted) 


图 5-2 ”Gertit 事 件 处 理 流程 
图 5-2 中 的 流程 说 明 如 下 : 


1) Gerrit 向 Zuul-server 发 送 变 更 通知 消息 ， 这 些 消息 可 能 包括 : 新 增 代码 提交 (review) 、 针 对 某 个 提交 的 补丁 (patchset) 、 新 增 评论 (comments) 、 代 码 合 入 (git merge) 、 提 交 作 废 
(abandon) 等 。 


2) Zuul Server 收 到 Gerrit 的 事件 后 ,分析 事件 类 型 ， 如 果 是 变更 相关 消息 ， 则 匹配 是 否 存在 与 此 事件 相关 联 的 队列 ; 若 存 在 ， 则 把 事件 放 在 队列 尾 。 
3) Zuul server 从 匹配 的 队列 头 取 出 一 个 事件 进行 处 理 。 

4) Zuul Server 请 求 Zuul Merger 为 出 队 的 事件 准备 Git 代 码 仓 库 。 

5) Zuul Merger 把 目标 分 支 的 最 新 代码 和 本 次 变更 的 代码 进行 代码 合并 。 

6) Zuul Merger 通 知 Zuul Server Git 代 码 仓库 准备 就 绪 。 

7) Zuul Server 发 消息 给 Jenkins 执 行 相关 的 任务 。 

8) Jenkins 选 择 一 个 满足 条 件 的 Slave 执 行 相关 的 任务 。 

9) Jenkins 从 Zuul Merger 克 隆 代 码 并 执行 相关 的 测试 服务 。 

10) Jenkins 在 任务 执行 完成 后 向 Zuul Server 报 告 测试 执行 结果 。 

11) Zuul Server 把 任务 执行 结果 反馈 给 Gerrit， 如 果 Zuul Server 具 有 voting 权 限 ， 还 要 向 Gerrit 返 回 投票 结果 (1/52) 。 


以 上 是 一 个 简化 的 执行 流程 ， 忽 略 了 Zuul 和 外 部 模块 的 很 多 处 理 细节 ， 但 本 流程 足以 描述 Gerrit 事 件 触 发 后 ， 一 个 门 控 系 统 所 需要 完成 的 功能 。 流 程 中 涉及 的 术语 和 过 程 ， 将 在 后 续 的 章节 进行 描述 。 


5.1.1 Zuul 工 作 原 理 

Zuul 通 过 pipeline 定 义工 作 流 ， 可 以 说 pipeline 是 Zuul 中 最 重要 的 概念 。pipeline 定 义 了 一 个 可 应 用 于 一 个 或 多 个 项 目 (project) 的 工作 流 过 程 ， 是 对 执行 任务 的 条 件 、 验 收 准 则 和 通知 的 一 个 抽象 描 
述 ， 以 便于 自动 化 执行 。 以 OpenStack 社 区 为 例 ， 最 常用 的 三 个 pipeline 如 下 : 

- check pipeline: 描述 一 个 新 的 变更 必须 要 通过 哪些 测试 。 


: gate pipeline: 实现 项 目 门 控 ， 当 变更 的 所 有 测试 都 通过 后 ， 自 动 把 代码 合并 (merge) 到 对 应 分 支 。 


: post pipeline: 3$ 变更 合并 后 进行 发 布 处 理 ， 比 如 重新 发 布 项 目 文档 或 进行 部 署 。 


check、gate 和 Ppost 不 是 ZuulI 内 置 的 关键 字 ， 可 以 是 任意 名 称 ， 这 些 名 称 只 是 为 较 准 确 地 反映 操作 过 程 、 步 又 或 期 望 ， 这 里 只 是 列举 Zuul pipeline 几 个 常见 的 示例 。 一 旦 定义 了 pipeline， 任 何 项 目 
(参见 5.6.3 节 ) 都 可 以 使 用 这 个 pipeline， 同 时 指定 这 个 项 目的 哪些 任务 (参见 5.6.2 节 ) 在 这 个 pipeline 下 运行 。 


每 个 pipeline 都 有 自己 的 触发 器 ， 这 些 触 发 器 描述 了 把 某 个 事件 加 入 pipeline 的 规则 。 举 例 来 说 ， 当 一 个 补丁 被 提交 到 Gerrit 之 后 ， 就 触发 了 一 个 patchset-created 事 件 。 当 Zuul 收 到 这 个 事件 时 ， 一 个 
配置 了 patchset-created 事 件 触发 器 的 pipeline 就 会 把 这 个 变更 放 到 队列 中 。 如 果 这 个 pipeline 和 patchset 所 属 项 目的 任务 关联 ， 这 些 任务 就 会 被 触发 。Zuul 除 支持 Gerrit 触 发 器 外 ， 还 支持 定时 器 和 Zuu| 内 
部 事件 触发 ， 详 细 的 列表 可 以 参见 5.4 节 。 


pipeline 的 队列 是 一 种 基本 的 数据 结构 ， 具 有 先进 先 出 (FIFO, First-In-First-Out) 的 特点 ， 只 允许 在 尾部 插入 ， 头 部 删除 ， 如 图 5-3 所 示 。 但 需要 说 明 的 是 ，Zuul 可 以 根据 需要 ， 或 通过 命令 行 调整 
队列 中 某 个 元 素 的 优先 级 ， 例 如 把 某 个 事件 调整 到 队列 头 部 、 删 除 某 个 事件 等 。 


head | middle 


new trigger event 


pipeline queue 


图 5-3 ” pipeline 队列 示例 


在 pipeline 触 发 的 所 有 任务 运行 完成 之 后 ，pipeline 的 报告 器 (参见 5.5 节 ) 负责 上 报 所 有 任务 运行 的 结果 。 如 果 一 个 pipeline 配 置 了 Gerrit 报 告 器 ， 那 么 这 个 pipeline 会 向 Gerrit 系 统 提交 这 个 变更 的 评 
审结 果 (review comment) 。 如 果 Zuul 还 具有 Gerrit 系 统 上 的 投票 (voting) 权限 ， 还 会 提交 投票 结果 (+1 和 +2 分 别 表示 通过 /不 通过 和 批准 /不 批准 ) ， 有 具体 的 配置 参考 3.2 节 。 


每 个 进入 pipeline 队 列 的 条 目 都 会 与 一 个 引用 (git ref) 关联 ， 每 个 ref 都 指向 一 个 特定 的 变更 ， 或 者 只 是 某 个 分 支 或 标签 的 提示 。 触 发 器 事件 决定 ref 代 表 分 支 、 标 签 还 是 合并 提交 。Zuul 在 运行 任务 前 
为 其 准备 好 这 个 ref。Zuul 创 建 的 ref 是 以 Z 打 头 ， 后 接 一 串 32 字 节 的 16 进 制 数 (Git 本 身 的 ref 是 40 字 节 ) ， 为 便于 区 分 ， 后 续 称 之 为 zuul ref。 对 于 一 个 新 变更 ，Zuul 会 把 变更 合并 到 目标 分 支 ， 这 就 是 说 ， 
所 有 的 任务 都 是 基于 该 变更 合并 到 目标 分 支 之 后 执行 的 。 当 变更 被 创建 后 ， 远 端 代码 库 (也 就 是 Gerrit 服 务 器 中 的 代码 库 ) 可 能 已 经 合 入 了 一 些 其 他 变更 ， 从 某 种 意义 上 来 说 ，Zuul 准 备 的 代码 库 可 能 与 变 
更 初始 创建 时 不 同 。 如 果 在 pipeline 中 的 条 目 依 赖 于 其 他 条 目 ， 那 么 所 有 这 些 依 赖 变更 都 会 被 包含 在 Zuul 所 准备 的 Git 代 码 库 中 。 


图 5-4 是 一 个 典型 的 Git 修 改 历史 示意 图 。 提 交 b 和 提交 d， 都 是 基于 提交 a 进行 的 修改 。 同 时 主线 分 支 (示例 为 master) 在 提交 d 被 合 入 前 ， 依 次 合 入 了 b、c、e 三 个 提交 。 提 交 d 创 建 时 基于 提交 a 所 引用 
的 代码 库 ， 此 时 若 需要 对 提交 dj 进行 测试 ， 主 线 分 支 的 最 新 提交 (tip 已 经 发 生变 化 ， 直 接 使 用 变更 d 的 代码 进行 测试 将 无 法 验证 提交 d 与 主线 分 支 的 兼容 性 。Zuul-merger 会 获取 目标 分 支 的 最 新 提交 ， 即 
提交 e 所 引用 的 当前 状态 和 提交 d 的 修改 进行 合并 ， 得 到 Git 代 码 库 的 当前 状态 d'， 并 把 d' 提 供给 测试 任务 使 用 。 
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图 5-4 Zuul 代 码 合 并 处 理 流 程 


如 图 5-5 所 示 ， 执 行 具体 测试 的 Jenkins 任 务 并 不 直接 从 Gerrit 服 务 器 获得 代码 库 ， 而 是 从 Zuu| 的 代码 库 中 获取 。 而 Zuu| 则 为 测试 任务 合并 了 目标 分 支 (master) 的 最 新 提交 、 本 次 变更 的 代码 (变更 
123) 以 及 本 变更 所 依赖 的 一 系列 变更 ， 并 通过 git+ http 协 议 方式 提供 给 Jenkins 使 用 。 测 试 任务 不 再 需要 关注 代码 准备 过 程 ， 在 后 续 章 节 讲 解 pipeline 的 功能 时 你 将 体会 到 Zuul 这 种 服务 所 带 来 的 优势 。 


— Gerrit Server 


master branch . 


( ' Change 123 | ) 
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图 5-5 Zuul 为 变更 123 提 供 代 码 准 备 服务 


本 节 使 用 了 较 多 的 Git、Gerrit 和 Jenkins 中 定义 的 术语 ， 详 细 内 容 请 参考 相关 章节 。 


5.1.2 Zuul Server 


Zuul-cloner 一 


dependants... 


Zuul server 是 Zuu| 的 主要 组 件 ， 有 上 且 仅 有 一 个 实例 ， 不 可 扩展 。 只 有 当 Zuul Server 处 于 运行 状态 时 ，Zuul 才 可 以 进行 各 种 操作 。 它 从 配置 的 远程 系统 (参见 5.3 节 ) 的 连接 中 接收 事件 ， 并 把 它们 添加 
到 pipeline 列 表 中 ， 调 度 执 行 队列 中 的 事件 并 在 事件 执行 后 上 报 结果 。Zuul Server 还 提供 了 一 个 简单 的 Web 客 户 端 ， 可 以 浏览 当前 pipeline 的 信息 。 


图 5-5 中 ， 除 了 check、gate、post 这 三 个 基本 的 pipeline 外 ， 还 有 release (发 布 时 执行 ) 、periodic-weekly (每 周 执行 ) 等 自 定义 的 pipeline， 在 学 习 了 后 续 的 章节 后 ， 可 以 根据 需要 自行 添加 。 


Real-time status monitor of Zuul, the pipeline manager between Gerrit and Workers. 


Queue lengths: 0 events, 0 results. 


Filters 


check Q 


Newly uploaded patchsets enter this pipeline to receive an initial 
*/-1 Verified vote from Jenkins. 


tag 


This pipeline runs jobs in response to any tag event. 


silent 
This pipeline is used for silently testing new jobs. 


periodic-weekly 


Jobs in this queue are triggered on a timer. 


redeploy 


Have a change to redeploy the patchset when deployment 
procedure runs wrong. 


Zuul version: 2.5.2.dev70 


Expand by default: O 


gate O 


Changes that have been approved by core developers are 
enqueued in order in this pipeline, and if they pass tests in Jenkins, 


will be merged. 


pre-release Q 


This pipeline runs jobs on projects in response to pre-release tags. 


experimental Qo 


On-demand pipeline for requesting a run against a set of jobs that 
are not yet gating. Leave review comment of "check experimental" 
to run jobs in this pipeline. 


periodic-stable 


Periodic checks of the stable branches. 


reupdate 


Have a change to reupdate the patchset when deployment 
procedure runs wrong. 
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post Qo 


This pipeline runs jobs that operate after each change is merged. 


release-post O 


This pipeline runs release-process-critical jobs that operate after 
specific changes are merged. 


release Q 


When a commit is tagged as a release, this pipeline runs jobs that 
publish archives and documentation. 


periodic O 


Jobs in this queue are triggered on a timer. 


periodic-monthly O 


Jobs in this queue are triggered on a timer. 


merge-check O 


Each time a change merges, this pipeline verifies that all open 
changes on the same project are still mergeable. 


1.Zuul Serverit Æ 
Zuul Server 的 配置 在 zuul.conf 配 置 文件 中 ， 所 有 Zuu| 的 组 件 都 共享 该 配置 文件 。 其 中 与 Zuul Server 相 关 的 配置 参数 有 : 


: layout. config: layout.yaml 的 配置 文件 的 路 径 ， 必 须 存 在 ，Zuul pipeline 在 layout_conf ig 指 定 的 文件 中 配置 ， 仅 由 Zuul Setvet 使 用 。 


layout conf 


ig-/etc/zuul/layout.yaml 
:log config: 可 选 ， 日 志 的 配置 文件 ， 仅 由 Zuul Server 使 用 。 


log conf ig-/etc/zuul/logging.yaml 


: pidftle: PIDX fF, 44 t Zuul Setvet 使 用 。 


pidf ile-/var/run/zuul/zuul.pid 


state dir: 可 选 ，Zuul 状 态 保存 的 目录 ，Zuul 所 有 的 组 件 和 命令 都 使 用 。 


state dir-/var/lib/zuul 


- feport times: 可 选 ， 在 上 报 文本 报告 时 ， 是 否 需 要 携带 每 个 job 已 经 运行 的 时 间 ， 仅 由 Zuul Serveri H o 


report times-true 


: utl pattern: 可 选 ， 如 果 设 置 在 外 部 系统 中 保存 日 志 ， 并 且 在 Gettit 中 链接 到 这 些 日 志 ， 可 以 设置 上 报 URL 的 路 径 模式 ， 仅 由 Zuul Setvet 使 用 。 


url pattern-http://logs.cibook.oz/(change.number)/(change.patchset]/ 
(pipeline.name)/(ijob.name]/(build.number) 


: job name in report: 可 选 ， 在 Gettit 中 上 报 job 的 运行 结果 时 ， 是 否 需要 上 报 job 名 称 ， 黑 认 不 上 报 ， 仅 上 报 URL， 仅 由 Zuul Serverf£ Jf o 


job name in report-true 


Gearman 服 务 器 的 配置 信息 有 : 


- Server: Geatrman 服 务 器 的 主机 名 或 1P 地 址 ， 如 果 使 用 Zuul 内 置 的 Gearman 服 务 器 ， 服 务 器 地 址 设置 为 127.0.0.1 即 可 。 


server-gearman.cibook.oz 


: Port: 可 选 ，Geatman 服 务 器 的 监听 端口 ， 默 认 4730。 


port-4730 


2.Zuul Server® 


在 命令 行 下 运行 zuul-server 可 以 启动 Zuul Server， 杀 掉 相 应 进程 ， 即 可 停止 Zuul Server 服 务 。zuul-server 命 令 行 的 基本 使 用 方法 如 代码 清单 5-1 所 示 。 


Rp 


代码 清单 5-1 Zuul Server 命 令 行 使 用 参考 


usage: zuul-server [-h] [-c CONFIG] [-1 LAYOUT] [-d] [-t] [--version] 
Project gating system. 
optional arguments: 
-h, --help show this help message and exit 
-c CONFIG specify the config file 
-1 LAYOUT specify the layout file 


-d do not run as a daemon 
=E validate layout file syntax 
-—-version show zuul version 


S —4— 


可 以 通过 -d 参 数 让 Zuul 运 行 在 非 守护 状态 ， 这样 可 以 快速 检查 配置 文件 中 的 问题 。 正 常情 况 下 ,没有 -d 参 数 ，Zuul 会 以 守护 进程 的 方式 运行 。 


5.1.3 Zuul Merger 


Zuul Merger 是 一 个 独立 组 件 ， 能 通过 Gearman (参见 9.1 节 ) 与 Zuul Server 通 信 。Zuul Merger 在 其 工作 过 程 中 进行 一 系列 的 Git 操 作 ， 其 目的 
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每 个 Zuul 准 备 进行 的 测试 提供 独立 的 代码 合并 服 


务 ， 每 一 个 将 要 测试 的 变更 都 单独 地 与 目标 分 支 的 最 新 提交 进行 合并 ， 以 确保 该 变更 是 可 合并 的 ， 同 时 保证 ，Zuul 所 触发 的 测试 能 准确 地 表示 合并 变更 后 的 结果 。Zuul Merger 向 测试 工作 节点 (运行 


\ 一 /一 


Jenkins 任 务 的 节点 ) 提供 Git 代 码 库 服务 ， 而 这 些 Git 操 作 是 CPU 资源 消耗 密集 型 的 任务 ， 可 以 在 不 同 的 主机 上 运行 多 个 Zuul Merger 服 务 以 进行 负荷 分 担 。 


如 果 有 多 台 Zuul Merger 服 务 器 ， 请 确保 zuul_url 在 每 台 运 行 Zuul Merger 的 主机 上 的 设置 是 正确 的 ， 且 各 不 相同 。 如 图 5-7 所 示 ， 两 个 Zuul Merger 对 外 的 Git 服 务 的 地 址 分 别 


是 http://a.cibook.oz/p 和 和 http://b.cibook.oz/p。 


zuul-merger BEEN - zuul-merger 
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图 5-7 两 个 Zuul Merger 
在 Apache 服 务 器 上 进行 如 代码 清单 5-2 所 示 的 配置 ，Zuul Merger 就 可 以 提供 基于 http 的 Git 代 码 库 服务 。 


代码 清单 5-2 Apache 配置 参考 


SetEnv GIT PROJECT ROOT /var/lib/zuul/git 

SetEnv GIT HTTP EXPORT ALL 

AliasMatch ^/p/(.*/objects/[0-9a-f](2]/[0-9a-£](38]) 9 /var/lib/zuul/git/$1 
AliasMatch ^/p/(.*/objects/pack/pack-[0-9a-f][40]. (pack|idx))$ /var/lib/zuul/git/$1 
ScriptAlias /p/ /usr/lib/git-core/git-http-backend/ 


1.Zuul Merger & 

Zuul Merger 也 从 zuul.conf 文 件 中 读 取 配置 ， 需 要 对 gearman、gerrit、merger 和 zuul| 等 配置 块 进行 配置 。 
(1) gerrit 

Gerrit 服 务 器 的 配置 信息 。 


: Server: Gettit 服 务 器 的 域名 或 IP 地 址 。 


server-gerrit.oz 


. port: 可 选 ，Gertit 服 务 器 的 ssh 端 口号 ， 默 认为 29418。 


port-29418 


- usert: ssh 方 式 访问 Gettit 服 务 器 的 用 户 名 ， 添 加 comments 和 访问 stteam-events。 


user-cibook 


< sshkey: ssh 方 式 访问 Gettit 服 务 器 所 使 用 的 密 铀 。 


sshkey-/var/lib/zuul/ssh/id rsa 


(2) merger 
Zuul Merger 运 行 相关 的 配置 信息 如 下 所 示 : 


git_dir: Zuul 克 隆 代码 时 保存 在 本 地 的 路 径 。 


git dir-/var/lib/zuul/git 


git user email: 可 选 ，Zuul 本 地 合并 代码 时 所 使 用 的 email 账 号 ， 将 传递 给 git config user.email; 


git user email=zuul@example .com 


* git user name: 可 选 ，Zuul 本 地 合并 代码 时 所 使 用 的 Git 账 号 ， 将 传递 给 git config user.name. 


git user name=cibook 


: zuul url: Zuul 对 外 提供 的 Git repo 的 地 址 ， 通 常 使 用 https://zuul.cibook.oz/p 这 种 格式 。 


zuul url-https://zuul.cibook.oz/p 


(2) Zuul Merger 使 用 


在 命令 行 下 运行 zuul-merger 即 可 启动 Zuul Merger 服 务 。 


Zuul 对 于 创建 的 zuul ref 并 不 进行 垃圾 回收 ， 如 果 需 要 清理 这 些 引 用 ， 可 以 对 每 个 Git 库 运行 tools/zuul-clear-refs.py 这 个 脚本 ， 可 以 清理 早 于 一 定 日 期 (默认 为 360 天 ) 的 所 有 Zuul 引 用 : 


./tools/zuul-clear-refs.py /path/to/zuul/git/repo 


5.1.4 Zuul Cloner 

Zuul Cloner 是 一 个 简单 的 命令 行 客户 端 ， 用 于 从 Zuul 引 用 所 指定 的 项 目 库 克隆 (clone) 文件 。Zuul Cloner 优 先 使 用 ZUUL _URL 环 境 变量 指定 的 地 址 克隆 代码 ， 如 果 没 有 ZUUL _URL 环 境 变 量 ， 就 使 
用 配置 文件 中 的 配置 。 

1.Zuul Cloner 配 置 

Zuul Cloner 重 用 了 Zuul 的 参数 ， 比 如 ZUUL BRANCH, ZUUL REF 和 ZUUL PROJECT, 

它 将 尝试 从 环境 变量 中 获取 这 些 变 量 ， 当 然 也 可 以 通过 命令 行 参数 进行 传递 。 命 令 行 参数 使 用 zuul 前 级 ， 比 如 环境 变量 ZUUL_REF 通 过 命令 行 参数 zuul-ref 来 进行 传递 。 

Clone map 


默认 情况 下 ，Zuul Cloner 把 项 目 克 隆 在 basepath 所 指定 的 目录 下 ， 如 果 项 目 名 称 中 包括 字符 /， 则 说 明 项 目 名 称 使 用 了 多 级 目录 的 层级 形式 ， 那 么 默认 情况 下 Zuul Cloner 会 创建 所 有 这 些 子 目 录 。 如 
果 需 要 修改 目标 路 径 ， 可 以 通过 clonemap 来 进行 配置 。 配 置 文件 使 用 AML 格 式 ， 通 过 -m 人 参数 指定 。 如 下 所 示 : 


clonemap: 
- name: 'project' 
dest: '.' 


如 果 需 要 去 除 一 些 子 目录 ， 可 以 通过 正则 表达 式 来 修改 。 比 如 克隆 项 目 thirdpartWpluginsplugin1 时 ， 和 希望 去 除 thirdparty 目 录 ， 直 接 克隆 到 目标 目录 pluginsplugin1 下 。 如 代码 清单 5-3 所 示 ， 通 过 
\1 这 个 正则 表达 式 的 反 向 引用 ， 工 作 目 录 就 会 只 包括 ./plugins/plugin1 路 径 ， 而 project 项 目 则 创建 在 当前 目录 下 。 


代码 清单 5-3 ”修改 克隆 的 目标 目录 


clonemap: 
- name: 'project' 
dest: '.' 
- name: 'thirdparty/ (plugins/.*)' 
dest: 'M' 


最 终 的 映射 关系 如 代码 清单 5-4 所 示 : 


代码 清单 5-4 ”目标 路 径 映 射 关 系 


project -> ./ 
thirdparty/plugins/pluginl -> ./plugins/pluginl 


2.Zuul Cloner 人 使 用 


通常 ， 可 以 通过 zuul-cloner-h 来 获得 帮助 ， 如 代码 清单 5-5 所 示 。 


代码 清单 5-5 ”zuul-cloner 命 令 行 使 用 参考 


# zuul-cloner -h 


usage: zuul-cloner [-h] [-m CLONE MAP FILE] [--workspace WORKSPACE] [-v] 
[--color] [--version] [--cache-dir CACHE DIR] 
[--branch BRANCH] [--project-branch PROJECT-BRANCH] 
[--zuul-branch $ZUUL BRANCH] [--zuul-ref $ZUUL REF] 
[--zuul-url $ZUUL URL] [--zuul-project $ZUUL PROJECT] 
[--zuul-newrev $ZUUL NEWREV] B 
git base url projects [projects http://www.hzcourse.com/resource/readBook?path-/openresources/teach ebook/uncompressed/17933/OEBPS/Text/...] 


Zuul Project Gating System Cloner. 


位 置 相关 参数 : 
git_base_utl: 进行 软件 仓库 克隆 的 基础 地 址 。 
` projects: 需要 克隆 的 项 目 列 表 。 
可 选 参数 : 
:-m: 指定 Clone Map 文 件 。 
- —workspace: 克隆 的 目标 路 径 。 
- —-cache-dir: 克隆 的 缓存 路 径 。 
项 目 相 天 参数 : 
` -branch: 指定 检 出 的 分 支 ， 而 不 使 用 Zuul 指 定 的 分 支 ， 比 如 指定 另 一 个 分 支 用 来 测试 客户 端的 兼容 性 。 
* —project-branch: 项 目 相 关 的 分 支 ， 该 参数 比 --btanch 具 有 更 高 的 优先 级 。 
zuul-cloner 以 下 面 的 次 序 尝试 查找 Git 引 用 : 


1) 指定 分 支 的 Zuul 引 用 


2) 主 分 支 的 Zuul 引 用 

3) 指定 分 支 的 最 新 提交 (tip) 

4) 主 分 支 的 最 新 提交 

指定 分 支 是 下 列 分 支 之 一 : 

1) 项 目 指定 的 branch (从 project branches 参 数 中 获得 
2) 用 户 指定 的 branch (从 branch 参 数 中 获得 ) 


3) ZUUL BRANCH 指定 的 branch (从 zuul_branch 参 数 中 获得 ) 


Wi 


3. 克 隆 次 


当 克 隆 项 目 库 时 ， 目 标 目录 不 可 以 存在 ， 否 则 Git 克 隆 会 报错 。 由 于 Zuul Cloner 支 持 一 次 克隆 多 个 项 目 ， 如 果 在 克隆 父 项 目 之 前 克隆 子 项 目 就 会 发 生 目 录 已 存在 的 错误 ， 比 如 : 


zuul-cloner project/plugins/pluginl project 


这 条 命令 在 克隆 plugin1 项 目 时 ， 创 建 了 project 目 录 ， 当 克隆 project 项 目 时 就 会 发 生 错误 。 调 整 次 序 ， 先 克隆 父 项 目 再 克隆 子 项 目 ， 就 可 以 解决 : 
4. 缓 存 项 目 库 


--Cache-dir 参 数 可 以 通过 从 本 地 代码 库 克 隆 ， 从 而 降低 网 络 流量 ,但 本 地 项 目 库 可 能 不 是 最 新 的 。 如 果 --cache-dir 参 数 存 在 ，Zuul Cloner 将 会 先 尝试 从 该 目录 克隆 所 有 它 需 要 处 理 的 Git 代 码 库 ， 然 后 
把 克隆 下 来 的 代码 库 的 origin remote 的 URL 重 置 为 git_url_base， 青 进行 上 游 项 目 库 同步 ， 这 样本 地 代码 库 就 会 包含 所 有 远 端 变 更 信息 了 。 


--Cache-dir 参 数 默 认 从 环境 变量 ZUUL CACHE_DIR 中 获取 。 


5.1.5 Zuu| 客 户 端 


Zuul 有 一 个 简单 的 命令 行 客户 端 ， 管 理 员 可 以 用 它 来 修改 Zuu| 的 运行 行为 。 这 个 客户 端 程序 需要 可 以 访问 Gearman 服 务 器 ， 比 如 : 在 Zuul 服 务 器 所 在 的 主机 就 可 以 访问 。 


可 以 通过 以 下 命令 来 获得 更 多 的 帮助 : 


zuul [enqueue|enqueue-ref|promote|show] --help 


通过 以 下 的 命令 ， 把 example_project 项 目的 12345 变 更 的 1 号 补丁 放 入 check pipeline 队 列 尾 : 


zuul enqueue --trigger gerrit --pipeline check --project example project --change, ,—»12345,1 
通过 以 下 的 命令 ， 把 12345 变 更 的 1 号 补丁 和 13336 变 更 的 3 号 补丁 调整 到 check pipeline 队 列 的 头 部 : 
zuul promote --pipeline check --changes 12345,1 13336,3 

下 述 命令 可 以 显示 当前 正在 进行 的 任务 : 


zuul show running-jobs 


5.2 pipeline 


Zuu| 专 注 于 解决 如 何 合理 安排 变更 的 测试 顺序 ， 以 便 最 大 程度 地 并 行 测试 这 些 变更 。 门 ] 控 系统 需要 保证 测试 是 基于 变更 合 入 到 目标 分 支 的 最 新 提交 后 进行 的 。 一 个 简单 方法 就 是 ， 一 次 只 测试 一 个 变 
更 ， 如 果 通 过 测试 就 合 入 。 这 种 方式 看 起 来 很 好 ， 但 如 果 一 个 变更 的 测试 时 间 非 常 长 ， 开 发 人 员 就 必须 要 等 很 长 时 间 才 能 把 变更 合 入 到 目标 分 支 中 。 有 些 项 目 ， 测 试 任务 需要 人 花费 好 几 个 小 时 ， 而 开发 人 员 
创建 新 变更 和 提交 新 补丁 的 速度 远 比 测试 和 合 入 代码 要 快 很 多 ， 这 种 简单 方式 就 显得 更 加 力不从心 。 


Zuu| 支 持 两 种 pipeline， 分 别 是 依赖 型 pipeline 和 独立 型 pipeline。 由 于 依赖 型 pipeline 的 原理 比较 复杂 ， 而 且 是 门 控 系 统 的 最 核心 部 分 ， 下 面 将 结合 并 行 测试 进行 详细 阐述 。 


5.2.1 ”并行 测试 


Zuul 依 赖 型 的 pipeline 人 允许 并 行 执行 测试 任务 ， 同 时 确保 变更 得 到 正确 的 测试 ， 对 一 个 变更 而 言 就 像 只 有 这 个 变更 在 测试 。Zuul 假 设 所 有 的 测试 都 能 成 功 ， 这 样 所 有 的 变更 都 可 以 被 合并 。 如 果 有 某 个 
变更 失败 了 ， 我 们 期 望 其 他 变更 的 测试 任务 能 去 除 这 个 失败 变更 的 代码 ， 然 后 继续 进行 测试 ， 就 好 像 这 个 失败 的 变更 根本 没有 被 提交 一 样 。 理 想 情况 下 ， 期 望 尽 可 能 多 的 变更 被 并 行 测试 ， 尽 可 能 多 的 变更 
得 到 合 入 ; 最 差 情 况 下 ， 一 次 只 能 得 到 一 个 有 效 的 测试 结果 (每 个 变更 都 测试 失败 ， 队 列 中 第 一 个 变更 被 认为 测试 失败 ， 它 之 后 的 变更 都 需要 重新 测试 ， 原 理 在 后 续 部 分 详细 描述 ) 。 


举例 来 说 ， 核 心 开 发 者 短 时 间 之 内 迅速 批准 了 以 下 5 个 变 


A, BBC D, E 


ZuulI 会 把 这 5 个 变更 以 它们 被 批准 的 次 序 添加 到 依赖 队列 中 ， 并 增加 如 下 约束 : 


队列 中 每 个 后 续 变 更 都 依赖 它 在 队列 中 的 前 置 变更 。 


这 5 个 变更 在 队列 中 的 依赖 关系 如 图 5-8 所 示 ， 变 更 A 位 于 队列 首部 ， 变 更 E 位 于 队列 尾部 : 


Head 


Tail 


图 5-8 ”队列 中 5 个 变更 的 依赖 关系 


Zuul 随 后 并 行 启 动 这 些 变 更 的 测试 。 需 要 强调 的 是 : 如 果 某 个 变更 依赖 于 其 他 变更 ，Zuul Merger 会 把 它 依赖 的 变更 也 包含 在 内 ， 并 假设 它 依赖 的 变更 都 能 测试 通过 。 本 例 中 ，B 的 测试 任务 将 会 同时 
包含 B+A 变 更 的 内 容 ， 这 5 个 测试 任务 调度 如 下 所 示 。 


A 的 测试 任务 : 合 入 变更 A ， 然 后 进行 测试 

B 的 测试 任务 : 合 入 变更 A 和 B ， 然 后 进行 测试 

C 的 测试 任务 : 合 入 变更 A、B 和 C ， 然 后 进行 测试 

D 的 测试 任务 : 合 入 变更 A、B、C 和 D ， 然 后 进行 测试 

E 的 测试 任务 : 合 入 变更 A、B、C、D 和 FE ， 然 后 进行 测试 


因此 ， 变 更 A 测试 只 会 包含 A， 而 忽略 变更 B、C、D、E， 如 图 5-9 所 示 。 


Merged changes for A 


Ignored changes 


图 5-9 ”变更 A 的 依赖 关系 


变更 E 的 测试 任务 将 包含 整个 依赖 链 上 的 变更 ， 也 就 是 包含 了 A、B、C、D 和 E 所 有 这 5 个 变更 。 变 更 E 的 测试 任务 假设 变更 A、B、C 和 D 都 能 通过 测试 ， 如 图 5-10 所 示 。 


Merged changes for E 


图 5-10 ”变更 已 的 依赖 关系 
如 果 变 更 A 和 B 都 通过 了 测试 ， 同 时 变更 C、D 和 E 都 测试 失败 了 ， 如 图 5-11 所 示 。 


master 


那么 Zuul 会 依次 合 入 变更 A 和 B， 并 从 队列 中 移 除 ， 剩 余 的 队列 如 图 5?-12 所 示 。 


图 5-11 变更 A 和 B 测 试 通过 


图 5-12 ”去 除 变 更 A 和 B 后 的 队列 


图 5-13 去除 变 更 C 后 的 队列 


Merged changes for D 


master 


图 5-14 重启 变更 D 依 赖 测 试 流程 


Merged changes for E 


master 


图 5-15 EA Zt E FRIMA 


由 于 变更 D 依 赖 于 变更 C， 无 法 确定 变更 D 的 测试 任务 失败 是 D 本 身 有 故障 还 是 C 导 致 。 变 更 E 的 情况 与 D 类 似 。 但 可 以 肯定 的 是 ， 变 更 C 测 试 失败 上 且 不 依赖 于 队列 中 任何 其 他 变更 ， 因 此 Zuul 会 上 报 变更 C 
测试 失败 ， 并 把 它 从 队列 中 删除 ， 保 留 变更 D 和 上 E。 


图 5-13 中 这 个 队列 就 像 两 个 新 变更 刚 加 入 队列 一 样 ，Zuul 会 重新 启动 针对 变更 D 和 E 的 测试 。 也 就 是 说 ， 变 更 D 的 测试 任务 只 会 包含 变更 D 本 身 (如 图 5-14 所 示 ) ， 而 变更 E 的 测试 任务 将 会 同时 包含 D 和 
E 的 修改 (如 图 5-15 所 示 ) ， 但 需要 注意 的 是 ， 此 时 新 队列 的 master 分 支 的 最 新 提交 已 经 发 生变 化 ， 因 为 变更 A 和 B 已 经 合 入 到 master 分 支 。 


在 了 解 了 Zuul pipeline 的 基本 功能 和 原理 后 ， 不 难看 出 Zuul 的 pipeline 的 调度 管理 和 Gerrit+Jenkins+ 门 控 任务 的 普通 门 控 系 统 有 着 较 大 的 不 同 。 
普通 门 控 系统 没有 队列 管理 功能 ， 只 能 进行 master+ 当前 变更 的 并 行 测试 。 
普通 门 控 系 统 无 法 保证 在 当前 测试 任务 通过 的 情况 下 ， 合 并 代码 后 ， 目 标 分 支 的 回归 测试 不 受 影响 。 


普通 门 控 系 统 没 有 去 除 测 试 失败 变更 的 自动 回 滚 机 制 。 


5.2.2 BRAMA 


当 有 多 个 项 目 互相 之 间 紧 耦合 时 ， 我 们 肯定 希望 进入 队列 的 变更 可 以 与 当前 队列 中 的 其 他 关联 项 目的 变更 一 起 测试 ， 因 为 关联 项 目的 变更 有 可 能 引入 了 阻塞 性 功能 ， 最 终 还 会 被 合 入 主线 分 支 。 举 例 来 
说 ， 服 务 器 、 客 户 端 类 型 的 项 目 ， 如 果 接 口 修改 不 能 兼容 ， 就 演变 为 紧 耦 合 的 两 个 项 目 。 当 一 个 接口 、 功 能 变更 同时 涉及 服务 端 和 客户 端的 修改 时 ， 某 一 个 变更 测试 通过 不 代表 该 功能 与 另 一 项 目的 最 新 版 
本 也 能 测试 通过 。 某 些 情况 下 ， 一 个 独立 的 变更 甚至 根本 无 法 测试 通过 。 


Zuul 不 仅 能 解决 同一 个 项 目 内 的 测试 任务 编排 ， 也 能 用 于 跨 项 目的 测试 任务 编排 。 这 种 跨 项 目 ， 甚 至 多 个 项 目的 依赖 关系 ， 通 过 在 同一 个 依赖 型 pipeline 中 注册 相同 的 测试 任务 ， 就 可 以 解决 这 种 紧 耦 


合 的 问题 。 


当 一 个 变更 进入 队列 时 ，Zuul 会 同时 创建 该 变更 对 其 他 项 目的 引用 。 举 例 来 说， 有 一 个 名 为 acme 的 主 项 目 和 一 个 名 为 plugin 的 插件 项 目 。 定 义 一 个 测试 任务 acme-tests， 这 两 个 项 目的 任何 一 个 变 
更 ， 都 会 触发 这 个 测试 任务 运行 ， 如 代码 清单 5-6 所 示 。 


代码 清单 5-6 ”共享 测试 任务 示例 


pipelines: 
# 创建 一 个 名 为 gate 的 依赖 型 pipeline 
- name: gate 
# 依赖 型 pipeline 
manager: DependentpipelineManager 
projects: 
- name: acme 
gate: 
# acme 项 目 在 gate pipeline 中 注册 acme-tests 测试 任务 
— acme-tests 
- name: plugin 
gate: 
# plugin 项 目 在 gate pipeline 中 注册 同一 个 测试 任务 
-— acme-tests 


当 一 个 变更 进入 该 pipeline 队 列 时 ，Zuul 会 为 它 创建 一 个 引用 ， 后 续 的 变更 进入 队列 时 ， 会 额外 增加 对 队列 中 前 置 变更 的 引用 。 这 样 ， 依 据 依赖 信息 ， 队 列 中 的 每 个 变更 都 可 以 正确 地 克隆 出 所 需要 的 
版 本 。 举 例 来 阅 ，3 个 变更 依次 进入 门 控 队 列 ，Zuul 对 于 每 个 变更 都 分 配 了 一 个 对 应 的 引用 ， 如 表 5-1 所 示 。 


表 5-1 Zuul 为 变更 序列 创建 引用 


MEL 


Change 3 plugin master/Z3 


+ 


由 于 变更 进入 的 是 依赖 型 的 pipeline， 因 此 ， 与 项 目 内 的 测试 类 似 ，Zuul 会 为 每 个 变更 创建 额外 的 引用 ， 如 表 5-2 所 示 。 
表 5-2 Zuul 为 变更 序列 创建 额外 引用 


Zuul 引用 T8 


master/Z] acme master + change 1 


变更 项 目 
] acme 
acme master/Z2 acme master + change 1 

plugin stable/Z2 plugin stable + change 2 
acme master/Z3 acme master + change 1 
3 plugin stable/Z3 plugin stable + change 2 


plugin master/Z3 plugin master + change 3 


N 


若 要 测试 变更 3， 需 要 克隆 这 两 个 代码 库 ， 同 时 把 Z3 引 用 应 用 于 这 两 个 项 目 库 的 每 一 个 project/branch 设 定 的 匹配 组 合 。 在 本 例 中 ， 需 要 克隆 : 

“ actme 项 目 : master 分 支 ， 应 用 Z3 引 用 ， 包 含 了 变更 1。 

plugin 项 目 : master 分 支 ， 应 用 Z3 引 用 ， 包 含 了 变更 3 但 不 包含 变更 2。 

acme 项 目的 master 分 支 和 plugin 项 目的 stable 分 支 ， 如 果 不 需要 组 合 测试 ， 则 不 需要 克隆 。 

当 测试 任务 需要 克隆 多 个 代码 库 ， 但 队列 中 没有 前 置 变 更 时 ， 入 队 时 就 不 会 存在 额外 的 引用 变更 ， 就 只 包含 变更 本 身 。 

一 个 依赖 型 的 pipeline 可 以 根据 需要 有 多 个 共享 变更 队列 ， 相 关联 的 项 目 共 享 一 个 变更 队列 ， 但 不 影响 不 相关 的 项 目 。 一 个 独立 型 的 pipeline 不 共享 队列 ， 但 仍然 可 用 于 跨 项 目的 交叉 依赖 测试 。 


依赖 型 pipeline 的 一 个 重要 的 特性 是 : 它 可 以 作为 被 不 同 项 目 触 发 的 公共 任务 ， 它 把 这 些 项 目 看 成 是 关联 项 目 并 共享 同一 个 虚拟 的 变更 队列 。 如 果 一 个 任务 对 两 个 项 目 进行 集成 ， 这 两 个 项 目 自然 就 共 
享 了 一 个 虚拟 的 变更 队列 。 如 果 一 个 第 三 方 项 目 不 使 用 这 个 任务 ， 它 就 在 这 个 虚拟 队列 的 范围 之 外 ， 变 更 也 就 会 与 这 两 个 项 目 无 关 。 


5.2.3 BREAKER 


Zuul 人 允许 用 户 通 过 在 git commit message 里 通过 特定 的 标注 指定 跨 项 目 依 赖 。Zuul 的 跨 项 目 依 赖 (Cross-Repository Dependencies, CRD) 的 行为 与 git 本 身 的 做 法 是 类 似 的 ， 通 过 一 个 有 向 无 环 图 
(DAG) 来 实施 。 同 一 个 库 中 一 个 变更 单 向 依赖 于 另 一 个 变更 ， 而 这 种 机 制 被 Zuul 借 鉴 用 于 不 同 项 目 库 之 间 ， 准 确 地 说 ， 任 何不 同 的 repo 之 间 的 依赖 都 可 以 使 用 这 种 机 制 ， 而 不 限于 是 否 是 跨 项 目 。 如 果 变 
更 A 依赖 B， 那 么 变更 B 束 不 可 以 依赖 变更 A,。 


在 Git 的 commit message 中 ， 包 含 关键 字 Depends-On:<gerrit-change-id> 就 可 以 向 Zuul 指 示 这 种 依赖 关系 。 注 意 ， 需 要 使 用 完整 的 以 字母 | 开头 的 40 字 节 的 变更 号 。 通 过 gerrit-change-id 可 以 从 
Gerrit 系 统 中 查询 到 具体 的 变更 信息 。 具 体 看 一 个 依赖 的 例子 : 


Depends-On: 1835ddcb90c3b75978eb80a0163d74fa2a254ab99a 


1. 依 赖 型 pipeline 


在 处 理 CRD 变 更 时 ，Zuul 会 把 这 些 具有 依赖 关系 的 变更 放 到 同一 个 列队 中 进行 序列 化 ， 也 就 是 说 ， 如 果 变 更 A 依赖 于 变更 B， 那 么 变更 A 和 B 会 被 加 入 到 一 个 依赖 型 pipeline 中 ， 而 且 在 队列 中 变更 B 在 变 


更 A 的 前 面 ， 如 图 5-16 所 示 。 


Change B 
Change-Id: labc 


Change A 
Depends-On: Iabc 


图 5-16 ”依赖 型 pipeline 状 态 显 示 


如 果 变 更 B 测 试 失败 ， 那 么 变更 A 和 变更 B 都 会 被 从 pipeline 列 队 中 清除 。 
2. 独 立 型 pipeline 


相 比 于 依赖 型 pipeline， 独 立 型 pipeline 要 简单 得 多 。 所 有 变更 相互 之 间 都 是 独立 的 ， 整 个 pipeline 没 有 依赖 型 pipeline 采 用 的 共享 依赖 图 ， 然 而 对 于 每 一 个 待 测试 的 变更 而 言 ，Zuul 通 过 Zuul 引 用 准备 
好 它 所 有 的 依赖 ， 然 后 进行 测试 。 


当 变 更 被 添加 到 独立 型 pipeline 队 列 时 ， 变 更 本 身 的 依赖 (包括 正常 的 来 自 于 父 提交 的 依赖 和 CRD 变 更 ) 会 像 使 用 依赖 型 pipeline 一 样 出 现在 本 变更 的 依赖 图 中 。 也 就 是 说 ， 即 使 在 独立 型 pipeline 中 ， 
更 测试 仍然 是 在 合 入 它 所 有 的 依赖 后 进行 的 。 通 过 这 种 机 制 ， 一 些 其 他 代码 仓库 中 不 能 进行 完整 测试 的 变更 在 被 依赖 时 被 触发 进行 测试 。 


如 果 在 Web 客 户 端 状态 页 面 浏览 这 个 依赖 图 ， 可 以 看 到 到 依赖 变更 会 被 显示 为 灰色 的 圆圈 ， 而 实际 被 测试 的 变更 显示 为 红色 或 绿色 ， 取 决 于 任务 的 测试 结果 ， 成 功 为 绿色 ， 失 败 为 红色 。 


如 图 5-17 所 示 ， 灰 色 (E) 的 圆圈 说 明 变 更 仅 用 于 其 他 变更 的 依赖 。 即 使 某 个 变更 当前 正在 测试 ， 但 它 作 为 依赖 变更 时 ， 仍 然 显示 为 灰色 ; 作为 当前 的 测试 变更 时 ， 它 会 显示 为 红色 或 绿色 。 


图 5-17 独立 型 pipeline 状 态 显 示 


3. 多 个 变更 依赖 


一 个 Gerrit 变 更 号 可 以 指向 多 个 变更 (属于 同一 个 项 目的 多 个 分 支 ， 甚 至 多 个 项 目 ) 。 在 这 种 情况 下 ，Zuul 会 把 所 有 这 些 引用 的 变更 都 看 作 依赖 。 如 果 项 目 A 的 一 个 变更 A1 依 赖 于 项 目 B 的 一 个 变更 号 
1123， 但 I123 在 项 目 B 的 两 个 分 支 都 有 变更 ， 此 时 ， 测 试 A1 这 个 变更 时 ， 项 目 B 的 两 个 变更 都 会 被 用 于 依赖 。 变 更 A1 只 有 在 项 目 B 的 这 两 个 变更 都 已 经 合 入 的 情况 下 才能 合 入 ， 如 图 5-18 所 示 。 


当然 ， 一 个 变更 也 可 以 依赖 于 多 个 Gerrit 变 更 号 。 项 目 A 可 以 同时 依赖 于 项 目 B 和 项 目 C 的 变更 号 ， 而 这 只 需要 增加 多 行 Depends-On 即 可 。 如 图 5-19 所 示 ， 项 目 A 的 变更 同时 依赖 于 项 目 B 变 更 号 为 1123 
9 变更 和 项 目 C 变 更 号 为 labc 的 变更 。 


Dependencies 


Repo B Change-Id: 1123 
Branch: stable 


Repo B Change-Id: 1123 
Branch: master 


Repo A 
Depends-On: 1123 


Dependencies 


Kepo B 
Change-Id: 1123 


Repo C 


Change-Id: labe 


Repo A 
Depends-On: I123... 


图 5-19 ”依赖 多 个 变更 号 


5.3. ”连接 器 


Zuul 通 过 连接 (connection) 概念 与 多 个 不 同系 统 进行 通信 。 连 接 信 息 配置 在 zuul.conf 文 件 中 ， 在 layout.yml 文 件 引 用 这 些 配置 。 通 过 这 种 方式 ，Zuul 可 以 用 一 个 连接 从 Gerrit 服 务 器 接收 事件 ， 却 使 
用 另 一 个 连接 上 报 结果 ， 这 两 个 连接 使 用 不 同 的 账号 。 


5.3.1 Gerrit 


创建 一 个 到 Gerrit 服 务 器 的 连接 。 


driver-gerrit 


- server: Gerrit 服 务 器 地 址 信息 。 


server-gerrit.cibook.oz 


: port: 可 选 ，Gettit 服 务 器 端口 。 


port-29418 


* baseurl: 可 选 ，Gerttit 服 务 器 的 web 接 口 ， 默 认 设 置 为 https://<value of server? / 


baseurl-https://gerrit.cibook.oz/ 


- user: 登录 Gettit 服 务 器 的 ssh 的 用 户 名 。 


user-zuul 


“ sshkey: 登录 Gettit 服 务 器 的 ssh 的 密 钥 文件 。 


sshkey-/home/zuul/.ssh/id rsa 


` keepalive: 可 选 ， 连 接 的 保 活 时 长 ，0 表 示 不 保 活 。 


keepalive-60 


Zuul| 通 过 SSH 访 问 Gerrit 服 务 器 ， 因 此 需要 给 Zuul 提 供 一 个 Gerrit 服 务 器 的 SSH 账 号 。 如 果 这 个 账号 没有 配置 密 钥 访 问 ， 需 要 为 此 用 户 在 Gerrit 服 务 器 上 添加 公 钥 。 比 如 ， 下 面 的 命令 在 gerrit.cibook.oz 
服务 器 上 , 创建 了 一 个 cibook 账 号 ， 并 使 用 ~ /id_rsa.pub 文 件 中 的 内 容 作为 SSH 的 公 钥 。 


cat ~/id rsa.pub | ssh -p29418 gerrit.cibook.oz gerrit create-account --ssh-key \ 
- --full-name CIBook cibook 


并 且 需 要 在 Gerrit 服 务 器 上 为 此 用 户 进行 合适 的 权限 配置 以 满足 进行 门 控 系统 的 要 求 。 举 例 来 说 ， 配 置 Verif ied+ 1/-1 的 权限 ， 用 于 指示 该 变更 是 否 通过 测试 ; 配置 Submit 权 限 ， 以 便于 在 gate 
pipeline 通 过 时 ， 把 代码 合 入 到 主干 分 支 。 除 此 之 外 ， 还 可 以 配置 一 些 其 他 权限 ， 这 取决 于 需要 Zuul 完 成 什么 任务 ，Zuul 的 配置 非常 灵活 ， 很 容易 进行 适 配 。 


Qui 


SSH 用 户 必 须 具 有 stteam-events 的 权限 ， 和 否则 Zuul 无 法 收 到 Gettit 触 发 事件 。 


5.3.2 SMTP 


创建 一 个 到 SMTP (Simple Mail Transfer Protocol) 服务 器 的 连接 。 


driver-smtp 


- server: SMTP 服 务 器 的 主机 名 或 IP 地 址 。 


server-localhost 


port: 可 选 ，SMTP 服 务 器 端口 号 。 


port-25 


. default from: 邮件 报告 的 默认 发 件 人 的 邮件 地 址 ， 该 参数 可 以 在 pipeline 中 重 定义 。 


default from=zuul@cibook.oz 


: default to: 邮件 报告 的 默认 收 件 人 的 邮件 地 址 ， 该 参数 可 以 在 pipeline 中 重 定义 。 


default to=you@cibook.oz 


54 HIRE 


Zuul 主 要 支持 Gerrit 作 为 触发 器 。 由 于 Zuul 采 用 模块 化 设计 ， 易 于 进行 扩展 ， 因 此 很 容易 支持 其 他 触 上 友和 上 报 系统 。 


54.1 Gerrit 


Zuul 可 以 和 标准 的 Gerrit 系 统 对 接 ， 通 过 在 SSH 连 接 上 执行 gerrit stream-events 标 准 命令 来 获得 事件 通知 ， 上 报 也 在 该 接口 上 进行 。 
如 果 使 用 Gerrit 2.7 或 者 更 新 的 版 本 ， 需 要 确保 配置 给 Zuul 的 用 户 所 在 组 带 有 Stream Events 权 限 ， 否 则 Zuul 将 无 法 执行 gerrit stream-events 命 令 。 


参见 图 5-20， 给 Zuu| 配 置 的 访问 Gerrit 的 账号 所 在 的 组 需要 在 Projects 一 Access 一 Global Capabilities 一 Stream Events 标 签 下 进行 配置 。 


All My Projects People Plugins Documentation 
List General Branches Tags Access Dashboards Create New Project 


search term 
Project All-Projects 


Edit | 
History: 
(gitweb) 
Global Capabilities 
Access Database 
| ALLOW $| Administrators 
Administrate Server 
| ALLOW + | Administrators 
| ALLOW £ | Administrators 
Priority 
| BATCH +| Non-Interactive Users 
Stream Events 
| ALLOW * | Non-Interactive Users 


图 5-20 Gerrit Stream Events 权 限 配置 
Gerrit 驱 动 的 连接 名 称 可 以 支持 多 种 事件 和 以 下 的 参数 : 
event; Getrit 系 统 的 事件 名 称 ， 比 如 patchset-created、comment-added、tef-updated。 该 字段 是 正则 表达 式 。 
- branch: 事件 对 应 的 分 支 名 称 ， 比 如 mastet 对 应 master 分 支 。 该 字段 是 正则 表达 式 ， 且 可 以 有 多 个 列表 。 


ref: 对 于 ref-updated 事 件 ，branch 参 数 无 效 ， 但 提供 tef 参 数 。 当 前 ，Gerrit 在 菜 种 程度 上 来 说 对 于 tef 的 处 理 有 些 特殊 ， 对 路 径 指 定 裸 引用 (在 ref 中 不 包含 前 级 ， 如 master) ， 对 其 他 使 用 全 路 径 引 用 (如 
refs/tags/foo) 。Zuul 使 用 Gerrit 提 供 的 参数 进行 精确 匹配 。 该 字段 是 正则 表达 式 ， 且 可 以 有 多 个 列表 。 


- approval: 仅 用 于 comment-added 事 件 中 ， 用 于 匹配 该 变更 的 评审 通过 信息 ， 比 如 code-review:2 用 于 匹配 代码 评审 的 记录 中 是 不 是 含有 +2。 该 参数 可 以 包含 多 个 变更 通过 的 信息 列表 。 


- email: 该 字段 适用 于 任何 事件 。 该 字段 使 用 正则 表达 式 对 操作 者 的 Gettit 账 号 使 用 email 进 行 匹 配 。 如 果 和 希望 对 多 个 email 进 行 匹 配 ， 必 须 使 用 YAML .的 列表 形式 。 请 确保 使 用 非 贪 焚 的 匹配 规则 ， 并 且 对 
于 分 隔 域名 的 .号 需要 使 用 转 义 符 \。 比 如 : email:^.*?(@example\.oreh， 域 名 exapmle.org 中 的 .中 需要 使 用 转 义 符 。 


.usetname: 该 字段 适用 于 任何 事件 。 该 字段 使 用 正则 表达 式 对 操作 者 的 Getrit 账 号 使 用 usetname 进 行 匹 配 。 如 果 和 希望 对 多 个 usetname 进 行 匹 配 ， 必 须 使 用 YAML 的 列表 形式 。 请 确保 使 用 非 贪 禁 的 匹配 规 
则 ， 并 且 对 于 .号 需要 使 用 转 义 符 \。 比 如 : username:^jenkins$. 


: comment: 仅 用 于 comment-added 事 件 。 它 使 用 一 个 正则 表达 式 列表 在 comment 字 符 事 中 搜索 。 如 果 任 一 正则 表达 式 匹 配 了 comment 字 符 串 ， 该 触发 器 就 匹配 了 。 比 如 : comment'tettigget 仅 当 变 更 的 
comment 文 本 中 包含 有 retrigger 字 符 串 时 匹配 。 


: require-approval: 该 字段 适用 于 所 有 事件 。 它 需要 变更 的 当前 补丁 满足 一 定 的 预定 义 条 件 〈 可 以 通过 事件 增加 ) 。 它 与 5.6.1 节 pipeline 的 require 使 用 相同 的 语法 描述 。 


: teject-approval: 和 teduite-apptoval 使 用 相同 的 格式 ， 只 是 当 条 目 满 足 时 ， 拒 绝 评审 通过 。 


5.4.2 Timer 
Zuu| 也 支持 简单 时 间 触 发 ， 它 支持 基于 cron 定 时 系统 服务 的 指令 格式 触发 pipeline 中 的 任务 。 时 间 触 发 不 需要 任何 的 连接 或 驱动 。 同 时 ， 时 间 触 发 器 也 可 以 使 用 一 个 timer 列 表 作 为 触发 器 。 时 间 触 发 会 
把 在 配置 文件 中 定义 的 时 间 信 息 作 为 一 个 事件 放 到 每 个 项 目的 pipeline 中 。 任 何 与 该 pipeline 相 关 的 任务 ， 当 事件 发 生 时 就 会 被 触发 执行 。 


timer 使 用 5 个 参数 ， 与 cron 系 统 服务 是 类 似 的 : 比如 ，0 0** 表 示 在 每 天 凌晨 00:00 分 运行 该 任务 :10 0**1 表 示 在 每 周二 上 午 10:00 执 行 该 任务 ， 具 体 可 以 参考 [1]。 需 要 注意 的 是 ， 第 5 个 参数 取 值 范围 
是 0-6，1 在 crontab 表 示 周 一 ， 但 在 zuul 中 表示 周二 ， 依 此 类 推 。 


[1] https://docs.acquia.com/article/cron-time-string-formato 


5.4.3 Zuul 内 部 事件 


Zuu| 基 于 内 部 的 动作 会 产生 一 些 事件 ， 也 支持 多 个 事件 列表 。Zuul 的 事件 不 需要 专门 的 连接 或 驱动 ， 它 们 以 列表 的 方式 使 用 。 
event: 事件 名 称 ， 当 前 支持 如 下 事件 : 
` ptoject-change-merged: 当 Zuul 合 并 一 个 变更 到 目标 分 支 时 ， 它 给 项 目 每 一 个 未 完成 的 变更 产生 一 个 该 事件 。 
- parent-change-enqueued: 当 Zuul 把 一 个 变更 加 入 到 pipeline 队 列 时 ， 它 给 该 变更 的 每 个 子 变更 产生 一 个 该 事件 。 


` pipeline: 只 对 parent-change-enqueued 事 件 有 效 ， 是 父 变更 被 放 到 队列 时 的 pipeline 名 称 。 


 frequire-approval: 适用 于 任何 事件 ， 需 要 满足 的 通过 条 件 ， 同 第 5.6.1 节 pipeline 的 require 使 用 相同 的 语法 描述 。 


: feject-approval: 同 tequte-apptoval， 二 者 只 是 作用 相反 ， 满 足 条 件 的 情况 下 拒绝 加 入 队列 。 


55 ”报告 器 


Zuul 以 配置 的 方式 上 报 测试 结果 ， 比 如 build pipeline 成 功 运行 之 后 ， 在 Gerrit 上 返回 一 个 成 功 (+1/+2) 的 评审 结果 。 


Zuul 报 告 器 一 般 有 三 种 处 理 阶段 : 开始 、 成 功 或 失败 。 每 个 阶段 都 可 以 有 多 个 上 报 ， 比 如 在 测试 开始 时 重 设 Gerrit 的 Verif ied 标 签 ， 并 且 发 送 一 封 邮 件 通知 。 


5.5.1 Gerrit 


与 从 Gerrit 服 务 器 获取 通知 事件 一 样 ，Zuul 也 使 用 ssh 协 议 向 Gerrit 服 务 上 报 结果 。 


传递 给 Zuul 的 参数 字典 被 用 于 向 Gerrit 服 务 器 上 报 结果 的 gerrit review 命 令 。 字 典 参数 的 值 如 果 是 布尔 值 true， 表 示 该 参数 必须 存在 ， 但 不 需要 一 个 数值 。 比 如 ，verif ied:1 表 示 gerrit review--verif 


ied 1，submit:true 则 表示 gerrit review--submit, 


5.5.2 SMTP 


SMTP 提 供 简单 的 email 上 报 功能 。 如 果 需 要 此 功能 ,需要 配置 SMTP 驱 动 ， 具 体 参 见 5.3 节 。 
使 用 该 报告 器 ， 需 要 在 zuul.conf 中 配置 SMTP 服 务 器 及 默认 的 to/from 人 信息。 每 个 pipeline 都 可 以 通过 参数 来 重新 设置 主题 (subject) 、 收 件 人 (to) 和 发 件 人 (from) 参数 ， 如 代码 清单 5-7 所 示 。 


代码 清单 5-7 ”pipeline 定 义 示 例 


pipelines: 
- name: post-merge 
manager: IndependentpipelineManager 
source: my gerrit 
trigger: 
my gerrit: 
- event: change-merged 
# 在 Pipeline 成 功 时 发 邮件 给 youQ&cibook.oz 
success: 
outgoing smtp: 
to: you8cibook.oz 
# 在 Pipeline 失败 时 发 送 主题 为 变更 {change} 失败 的 邮件 给 you@cibook .oz 
# 且 发 件 人 为 alternative@cibook.oz 
failure: 
internal smtp: 
to: you8cibook.oz 
from: alternativeQcibook.oz 
subject: Change {change} failed 


本 代码 清单 5-7 中 ， 在 post-merge 这 个 后 处 理 pipeline 中 ， 执 行 成 功 后 使 用 outgoing_smtp 连 接 器 向 you@cibook.oz 发 送 成 功 邮件 ; 执行 失败 后 使 用 internal_ smtp 连接 器 ， 向 you@cibpook.oz 发 送 主 
题 为 Change{ 变 更 号 }failed 的 邮件 ， 且 发 件 人 是 alternative@cibook.oz。 


5.6 ”配置 指导 


OpenStack 社 区 的 开发 全 部 是 基于 Gerrit 代 码 评审 系统 进行 的 ，Zuul 与 Gerrit 关 系 密切 ，Zuul 的 不 少 流程 是 为 Gerrit 定 制 开发 的 ， 而 Gerrit 为 适应 Zuul 和 社区 流程 的 需要 ， 也 需要 做 一 些 定制 配置 (无须 
修改 版 本 ) ， 比 如 增加 workflow 标 签 。 到 目前 为 止 ， Zuul (V2) 只 支持 Gerrit 这 一 种 代码 管理 工具 。 在 浏览 具体 的 参数 之 前 ， 先 看 一 下 Gerrit 系 统 上 可 以 提供 的 信息 ， 这 些 信息 在 后 面 的 参数 说 明 中 将 要 使 
用 到 |。 


Gerrit 的 详细 说 明 请 参见 本 书 3.2 节 ， 这 里 重点 描述 与 Zuul 相 关 的 内 容 ， 如 图 5-21 所 示 。 
对 于 图 5-21 中 一 些 重 要 内 容 进 行 如 下 说 明 : 


1) Gerrit 系 统 中 提供 了 3 个 标签 (Label) 属性 : Code-Review、Verified 和 Workflow， 其 中 前 两 个 是 Gerrit 系 统 内 置 的 Label， 第 三 个 Workflow 是 Openstack 社 区 主要 使 用 的 一 个 Label， 主 要 目的 是 
为 了 完成 代码 提交 的 自动 化 ， 减 少 人 工 操作 。 当 有 两 个 2 (Clark Boylan 和 Jens 位 Harbott) 的 Code-Review 的 情况 下 ， 核 心 贡献 者 (Jens Harbott) 把 Workflow 设 置 为 +1， 这 就 触 上 大 了 进入 gate 


pipeline 流 程 。 
2) 547041 为 变更 号 ， 引 用 该 变更 的 URL 是 https://review.openstack.org/#/c/547041。 
3) 项 目 名 为 openstack-infra/project-conf ig， 该 名 称 也 是 Gerrit 中 的 repo 名 称 。 


4) 该 项 目 使 用 了 check 和 gate 两 个 pipeline， 每 个 pipeline 都 只 有 一 个 任务 ， 并 且 这 两 个 pipeline 共 享 了 同一 个 测试 任务 openstack-zuul-jobs-linters。 
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All Projects Documentation Sea rch term 
= 


is Openstack, un 


5 547041 
Change 547041 - Merged — 当前 状态 是 已 合 入 状态 Included in Y 


Limt jobs on release-tools presentations Owner Sean McGinnis 


We are adding some onboarding presentations to this repo with Reviewers Clark Boylan Jens Harbott (frickler) Zuul 
https://review.openstack.org/545066/. Since most jobs are not 

interesting when things will change under this /presentations 项 目 名 称 一 ~ Doug Hellmann 

directory, this limits jobs to just pep8. Project openstack-infra/project-config 


Change-Id: 1402e108d325952a0c2837e45a7238ba7edlifd01 项 目 分 支 名 称 一 人 ranch master 
Topic release-tools 


这 个 是 Code-Review 属性 的 值 Updated ^ 14 hours ago 


这 个 是 Verified 属性 的 值 
oo +2 Clark Boylan Jens Harbott (frickler) 
这 个 是 Workflow 属性 的 值 一 verfied — «2 Zu 


Workflow +1 Jens Harbott (frickler) 
Author Sean McGinnis «sean.mcginnis 9 huawei.com- Feb 22, 2018 11:53 PM 
Committer ^ Sean McGinnis «sean.mcginnis 9 huawei.com» Feb 22, 2018 11:53 PM Zuul check Feb 23 12:23 AM 
Commit b0b7a987b9ac1fffd7d8443abb95d6e55faa2daa 4 (gitweb) openstack-zuul-jobs-linters SUCCESS in 3m 39s 
Parent(s) dc8df068f3c5706316e04b4b02c2f6047a89925c85 4j (gitweb) Zuul gate Mar 18 4:09 PM 
Change-ld | 140261084d325952a0c2837e45a7238ba7ed11fd01 L openstack-zuul-jobs-linters. SUCCESS in 3m 48s 


1" 变化 的 文件 列表 |] rape 


File Path Comments Size 
V Commit Message 
zuul.d/projects.yaml 20 ERN 
+18, -2 Dg 


图 5-21 ”Gertit 评 审 单 状态 
5) 本 次 变更 只 修改 了 一 个 文件 ， 即 zuul.d/projects.yaml。 


图 5-22 是 Gerrit 系 统 中 的 Comments 相 关 的 内 容 。 


History | Expand All 


Sean McGinnis Feb 22 11:55 PM «+ 
Uploaded patch set 1. 

Clark Boylan Mar 17 7:18 AM + 
Patch Set 1: Code-Review-«2 


Jens Harbott (frickler) Mar 18 4:00 PM © 
Patch Set 1: Workflow--1 Code-Review--2 


Zuul Mar 18 4:09 PM «+ 
Change has been successfully merged by Zuul 


图 5-22 ”Gertit 评 审 意见 

从 图 5-22 中 可 以 看 到 ， 在 Jens Harbott 同 时 发 表 了 Workf low+1 和 Code-Review+2 的 Comments， 大 约 9 分 钟 后 ，Zuu| 完 成 了 代码 提交 ， 核 心 贡献 者 没有 参与 Gerrit 的 Submit 过 程 。 
Zuul 有 三 个 配置 文件 ， 其 中 前 两 个 是 必需 的 : 

.zuul.conf: 使 用 INI 文 件 格式 ， 提 供 了 Zuul 运 行 所 需要 的 绝 大 部 分 配置 信息 。 

: layout.yml: pipeline 运 行 所 需 信 息 。 

: logging.conf: 可 选 的 python 日 志 配 置 文件 。 

所 有 的 Zuul 组 件 都 可 从 /etc/zuul/zuul.conf 文 件 中 读 取 配置 ， 当 然 也 可 以 从 命令 行 指定 其 他 文件 。 同 时 需要 为 Zuul 准 备 一 个 Gerrit 库 的 账号 用 于 Zuul 访 问 Gerrit 代 码 库 。 详 细 配 置 参 见 5.3 节 。 
zuul.conf 文 件 示例 参见 代码 清单 5-8。 


代码 清单 5-8 ”zuul.conf 配 置 文件 


[zuul] 

layout config-/etc/zuul/layout.yaml 
[merger] 
git dir-/git 
zuul url-http://zuul.cibook.oz/p 
[gearman server] 

start-true 

[gearman] 

server-127.0.0.1 

[connection gerrit] 
driver-gerrit 
server-gerrit.cibook.oz 
port-29418 
baseurl-http://gerrit.cibook.oz 
user-cibook 
sshkey-/home/zuul/.ssh/id rsa 


本 章 前 面 的 章节 已 经 详细 描述 过 zuul.conf 中 各 参数 的 含义 ， 此 处 不 再 详 述 ， 后 文 重点 讲解 layout.yaml 相 关 的 关键 参数 。 


5.6.1 pipeline 


Zuul 有 许多 pipeline 的 参数 ， 当 某 个 pipeline 与 Gerrit 的 基 个 事件 匹配 时 ， 这 个 事件 就 会 被 添加 到 pipeline 的 队列 ， 与 这 个 pipeline 相 关 的 job 就 会 被 调度 执行 。 当 该 事件 触发 pipeline 的 所 有 job 都 执行 完 
成 时 ，ZuuI 会 向 Gerrit 报 告 测试 执行 结果 。 本 章 描 述 pipeline 的 基本 原理 时 ， 也 说 明 过 Zuul 不 存在 预定 义 的 pipeline， 因 此 可 以 根据 需要 在 layout.yml 中 定义 任意 的 pipeline， 同 时 pipeline 的 数目 也 没有 限 
制 。Zuul pipeline 这 种 灵活 的 机 制 可 以 适应 任何 实际 工作 流 的 需要 。 


: name: pipeline 的 名 称 ， 后 续 在 定义 job 时 需要 引用 ， 这 个 与 jb 的 宏 定义 的 使 用 是 类 似 的 。 
source: 给 Zuul 提 供 触 发 事件 、 变 更 控制 的 系统 ，Zuul 通 过 驱动 与 这 些 系统 进行 连接 ， 可 以 给 Zuul 添 加 不 同系 统 的 驱动 ， 可 扩展 性 很 强 ， 不 过 当前 只 支持 Getfit 驱 动 ， 该 参数 是 必 选 参数 。 


- Success-message: 可 选 ， 当 所 有 具有 投票 (voting) 权限 的 job 执行 成 功 之 后 ，Zuul 会 向 Gettit 上 报 成 功 结果 ， 默 认 是 Build Successful。 


success-message-Build Successful. 


: falure-message: 可 选 ， 当 任何 一 个 具有 投票 权限 的 job 执行 失败 之 后 ，Zuul 上 报 执行 失败 的 结果 ， 软 认 值 是 Build failed. o 


failure-message-Build failed. 


: merge-fallure-message: 可 选 ， 当 一 个 变更 的 当前 状态 无 法 合并 (Merge) 到 目标 分 支 时 (说明 存 在 变更 冲突 ) ，Zuul 会 向 Gerrit 上 报 合并 失败 的 消息 。 


merge-failure-message-Merge failed. 


: footer-message: 对 测试 结果 提供 额外 信息 ， 比 如 ， 对 CI 系统 提供 额外 的 调试 和 联系 方式 的 信息 还 是 比较 有 用 的 。 
: manager: 两 种 类 型 的 pipeline 的 管理 器 ，IndependentpipelineManager 和 Dependent-pipelineManaget 分 别 对 应 本 章 前 面 讲解 的 独立 型 pipeline 和 依赖 型 pipeline。 


: trigger: 一 个 pipeline 至 少 需 要 提供 一 个 触发 器 信息 ， 这 些 触 发 器 不 是 排 它 的 ， 即 一 个 pipeline 可 以 使 用 多 个 触发 器 ， 一 个 触发 器 也 可 以 在 多 个 pipeline 中 使 用 ， 在 这 些 pipeline 中 的 行为 也 是 独立 、 互 不 影 
响 的 。 


每 个 在 source 中 定义 的 驱动 ， 都 提供 了 不 同 触发 嚣 选项， 详细 信息 参见 5.4 节 。 

` require: 可 选 ， 进 入 pipeline 需 要 满足 的 预定 义 条 件 ， 而 不 管 该 条 件 是 如 何 进入 ， 无 论 是 通过 触发 器 触发 还 是 自动 依赖 引入 ， 本 参数 定义 的 条 件 必须 满足 ， 否 则 事件 不 能 进入 pipeline 队 列 。 
该 参数 定义 的 子 参数 较 多 ， 见 下 面 详细 说 明 : 

approval: 对 于 变更 要 求 批准 的 信息 满足 一 定 的 条 件 ， 它 本 身 也 有 多 个 子 参 数 ， 所 有 这 些 子 参 数 都 是 可 选 的 ， 且 可 以 组 合 使 用 ， 但 如 果 使 用 ， 则 需要 同时 都 满足 所 有 出 现 的 子 参 数 。 
username: 批准 变更 的 用 户 名 ， 使 用 正则 表达 式 表 示 。 

email: 批准 变更 的 邮箱 ， 使 用 正则 表达 式 表 示 。 

older-than: 变更 批准 需要 经 历 的 时 间 ， 通 常 支持 w (weeks). d (days) 、h (hours) 、m (minutes) 、s (seconds) 等 后 辍 ， 比 如 48h 表 示 48 小 时 ，2d 表 示 2 天 。 

newer-than: 和 older-than 使 用 相同 的 格式 ， 要 求 批准 必须 在 多 长 的 时 间 之 内 ， 这 两 个 参数 一 般 不 使 用 。 


除 上 述 参 数 外 ， 所 有 其 他 参数 都 被 解释 为 review 相 关 的 参数 。 比 如 verif ied:1 要 求 在 Gerrit 系 统 中 Verified 列 存在 +1 这 个 数据 ， 取 值 可 以 是 一 个 单一 值 ， 也 可 以 是 一 个 列表 ， 比 如 verif ied:[1，2] 要 求 或 
者 +1 或 者 +2 的 投票 存在 。 


open: 表示 进入 队列 的 变更 状态 是 未 合 入 状态 (open) 还 是 合 入 状态 (closed) ， 布 尔 值 。 


- cutrent-patchset: 表示 进入 队列 的 变更 是 否 需要 当前 最 新 的 补丁 ， 布 尔 值 。 在 Gettit 系 统 上 ， 可 以 浏览 一 个 变更 的 所 有 补丁 ， 黄 至 可 以 在 Gertit 上 触发 基于 某 个 历史 变更 的 测试 ， 比 如 使 用 techeck 来 触 
发 。 当 cuttent-patchet 设 置 为 Ttfue 时 ，Zuul 忽 略 除 最 新 补丁 之 外 的 其 他 触发 请 求 ; 当 cuttent-patchet 设 置 为 False 时 ， 变 更 的 任何 一 个 历史 补丁 都 可 以 触发 测试 ， 在 不 回 退 版 本 的 情况 下 ， 就 可 以 验证 某 个 历史 的 
补丁 的 效果 ， 这 个 特性 在 某 些 情况 下 非常 有 用 。 


"status: 表示 触发 器 上 报 事 件 的 当前 状态 的 字符 串 ， 比 如 NEW or MERGED., 
eject: 用 于 阻止 变更 进入 pipeline 队 列 ， 与 tequife 作 用 正好 相反 ， 使 用 与 tfequite 类 似 的 条 件 。 


- approval: 和 tequite 参 数 的 apptoval 一 样 ， 使 用 多 个 子 参 数 。 举 个 例子 ， 如 果 存 在 -1 或 -2 的 投票 结果 ， 则 拒绝 入 队 : 


reject: 
approval: 
- code-review: [-1, -2] 


: dequeue-on-new-patchset: 通常 ， 一 个 当前 正在 tfeview 的 变更 提交 了 一 个 新 补丁 ， 如 果 这 个 变更 已 经 在 pipeline 之 中 ， 那 么 会 从 pipeline 中 去 除 该 变更 的 旧 条 目 ， 并 取消 所 有 与 该 旧 条 目 相 关 的 、 包 括 依 赖 
该 变更 的 测试 任务 。 当 然 ， 可 以 通过 设置 参数 来 修改 这 个 默认 行为 ， 该 参数 为 布尔 值 。 


.ipgnote-dependencies: Zuul 会 尝试 把 当前 变更 的 所 有 依赖 变更 放 到 pipeline 中 该 变更 的 前 面 ， 这 样 所 有 这 些 依 赖 和 该 变更 可 以 被 一 起 测试 。 该 参数 是 布尔 型 参数 ， 默 认 取 值 是 false， 该 参数 只 对 独立 型 
pipeline 有 效 ， 把 该 参数 设置 为 ttue， 可 以 完全 取消 依赖 。 


success: 可 选 ， 描 述 所 有 测试 任务 完成 之 后 ，Zuul 如 何 向 Getrtit 上 报 结果 。 
. 如 果 参 数 不 存在 ， 所 有 任务 运行 成 功 之 后 ，Zuul 什 么 也 不 做 ， 甚 至 不 向 Gettit 上 报 任何 信息 。 
. 如 果 和 参数 存在 ， 将 会 使 用 一 个 上 报 播 件 列表 来 上 报 测试 结果 ， 每 个 条 目 代 表 了 一 个 播 件 连接 名 称 ， 取 决 于 为 此 连接 提供 的 驱动 。 


参见 5.5 节 的 详细 描述 。 


- falute: 使 用 与 success 一 样 的 语法 和 参数 ， 只 是 说 明 在 测试 失败 时 ，Zuul 如 何 处 理 。 


: merge-failure: 使 用 与 success 一 样 的 语法 和 参数 ， 只 是 说 明 在 合并 变更 失败 时 ，Zuul 如 何 处 理 。 如 果 该 参数 不 存在 ，failure 上 报 器 会 用 于 通知 不 成 功 的 合并 操作 消息 。 


start: 使 用 与 success 一 样 的 语法 和 参数 ， 只 是 说 明 合 并 在 被 添加 到 pipeline 队 列 时 ，Zuul 如 何 处 理 。 比 如 : 可 以 重 置 Gerrit 系 统 中 Verified 条 目的 值 。 


: disabled: 使 用 和 success 一 样 的 语法 和 参数 ， 只 是 说 明 变 更 的 目标 pipeline 被 禁用 时 ，Zuul 如 何 处 理 ， 参 见 dqisable-afterf-consecutive-failutes。 


* disable-after-consecutive-fallures: 可 选 ， 如 果 设 置 了 该 参数 ， 当 太 多 的 变更 接连 失败 ，pipeline 会 进入 禁用 状态 (disabled) 。 当 连续 的 失败 次 数 超过 该 值 时 ，Zuul 除 给 disabled 上 报 器 上 报 外 ， 会 停止 给 任 
何其 他 上 报 器 上 报 ， 无 论 是 success、failure 还 是 merge-failure。 当 pipeline 处 于 禁用 状态 时 ，start 上 报 器 也 不 会 上 报 。 


` precedence: 可 选 ， 指 示 对 于 不 同 的 pipeline 的 任务 如 何 按 优 先 级 进行 调度 。 每 个 pipeline 都 有 一 个 优先 级 ， 具 有 更 高 优先 级 的 pipeline 中 的 任务 比较 低 优先 级 的 任务 得 到 更 早 的 执行 。 该 字段 的 取 值 范围 
是 high、notmal 或 low。 


precedence-normal 


: window: 可 选 ， 仅 用 于 依赖 型 pipeline。Zuul 可 以 像 TCP 一 样 进行 流 控 。pipeline 队 列 会 有 一 个 窗口 值 ， 只 有 窗口 可 用 时 ( 即 大 于 0) ， 变 更 对 应 的 任务 才 会 被 执行 ， 窗 口 大 小 的 初始 值 被 设置 为 该 配置 
值 ， 配 置 值 是 一 个 正 整 数 ， 配 置 为 0 会 禁用 流量 控制 。 


window=20 


: window-floor: 可 选 ， 仅 用 于 依赖 型 Pipeline。 用 于 指示 window 的 最 小 值 ， 正 整数 。 


window-f loor-3 


分 别 了 解 一 下 在 Openstack 中 三 个 最 常用 的 pipeline: check、gate 和 post。 先 了 解 一 下 check pipeline 的 实际 例子 ，pipeline 根 据 需 要 使 用 相关 的 参数 。 


代码 清单 5-9 Check pipeline 示 例 


pipelines: 


# 定义 了 check pipeline 
- name: check 
description: Newly uploaded patchsets enter this pipeline to receive an initial +/,!-1 
Verified vote from Jenkins. 
+ 所 有 带 有 voting 权限 的 任务 成 功 执行 后 ， 向 Gerrit 增加 的 comment 消息 
success-message: Build succeeded (check pipeline). 
# f£—fH voting 权限 的 任务 执行 失败 后 ， 向 Gerrit 增加 的 comment 消息 


failure-message: Build failed (check pipeline). For information on how to, 


!proceed, see 


http: //docs.openstack.org/infra/manual/developers.htmli 


tomated- 


testing 


# 独立 型 pipleline 管理 器 
manager: IndependentpipelineManager 
# 使 用 Gerrit 作为 变更 的 数据 源 
source: gerrit 
# normal 等 级 的 pipeline 
precedence: normal 
+ 进入 该 pipeline 的 条 件 ， 要 求 处 于 open 状态 且 是 当前 补丁 
require: 
open: True 
Ue patchset: True 
# Gerrit 类 型 的 触发 器 ,与 source 保持 一 致 
trigger: 
gerrit: 
有 新 的 补丁 (patchset) 被 创建 时 


event: patchset-created 


# SEIT MOREM 
- event: change-restored 
# 或 者 有 新 的 评论 包含 recheck f, coment 中 使 用 了 正则 表达 式 表 示 方 式 


event: comment-added 
comment: (?i)^(Patch Set [0-9]+:)?( [NwNN*-] *) * (4nNn) ?Ns*recheck 
E HEND. 来 自 于 用 户 名 含有 jenkins 的 Verified 值 为 -1 或 -2 Hworkflow 被 置 为 ] 
event: comment-added 
require-approval: 
- verified: [-1, -2] 
username: jenkins 


4 


1 = 


approval: 
— workflow: 1 
# 执行 成 功 后 ， 在 Gerrit 设置 Verified 的 值 为 1 
Success: 
gerrit: 
verified: 1 
# 执行 失败 后 ， oa t 设置 Verified 的 值 为 -1 
failure: 
gerrit: 
verified: 一 ] 


对 代码 清单 5-9 中 check pipeline 的 一 些 重 要 信息 说 明 如 下 : 


1) 


2) it 


3) 


使 用 独立 型 (IndependentpipelineManager) pipeline， 优 先 级 为 normal。 
入 队列 时 ， 变 更 需要 处 于 Open 状 态 ， 且 只 有 该 变更 的 最 新 补丁 才 可 以 触发 测试 。 


有 4 种 Gerrit 事 件 可 以 触发 该 pipeline， 包 括 新 的 补丁 、 变 更 被 恢复 或 者 有 新 的 评审 意见 。 其 中 recheck 这 个 评论 方式 非常 有 用 ， 通 过 正则 表达 式 定义 了 一 个 包含 recheck 的 字符 串 (这 个 字符 串 格式 


需要 参考 Gerrit 系 统 comments 的 消息 定义 ) 。 如 果 依赖 项 目 或 基础 设施 出 现 问题 ， 在 这 些 问 题 被 解决 后 ， 变 更 本 身 并 不 需要 修改 ， 但 需要 有 能 力 重新 触发 测试 ， 这 个 示例 就 是 为 了 解决 该 问题 。 在 Gerrit 界 
面 的 Reply 消 息 框 中 输入 recheck 字 符 串 即 可 触发 任务 重新 执行 。 当 然 ， 这 个 正则 表达 式 可 以 定义 为 任何 其 他 方便 使 用 的 格式 ， 只 是 recheck 比 较 通用 


4) 


如 果 执 行 成 功 ， 在 Gerrit 上 设置 Verified 值 为 1;， 如 果 执 行 失 败 ， 在 Gerrit 设 置 Verified 的 值 为 -1。 


下 面 来 看 一 下 gate pipeline 的 实际 例子 ， 与 check pipeline 相 同 的 内 容 在 本 例 中 将 略 过 


代码 清单 5-10 Gate pipeline 示 例 


- name: gate 


http: //www.hzcourse.com/resource/readBook?path-/openresources/teach ebook/uncompressed/17933/OEBPS/Text/... 
Pee 管理 器 

manager: pendentpipelineManager 

# REI 作为 变更 的 数据 源 

source: gerrit 

# high 等 级 的 pipeline 

precedence: high 


# 进入 该 pipeline 的 条 件 ， 要 求 : 


# 处 于 open 状态 且 是 当前 补丁 ， 
# 并 且 来 自 于 用 户 名 包含 cibook 或 者 openzeroci 的 +1/2 的 Verified 结果 ， 
# 同时 workflow 是 1 
require: 
open: True 
current-patchset: True 
approval: 
- verified: [1, 2] 
username: (cibook|openzeroci) 
- workflow: 1 
# Gerrit 类 型 的 触发 器 ， 与 source 保持 一 致 
trigger: 
gerrit: 
+ 有 新 workflow 为 1 的 评论 
- event: comment-added 
approval: 
- workflow: 1 
# 或 者 有 新 的 Verified 的 值 为 1， 且 用 户 名 包含 cipook 或 openzeroci 
- event: comment-added 
approval: 
- verified: 1 
ername: (cibook|openzeroci) 
# 任务 开始 化 ， 把 Gezrit 上 的 Vecifica 的 值 设置 为 0 
start: 
ag 


# 所 有 带 5 让 限 的 任务 执行 成 功 后 ， 把 Gerrit 上 的 Verified 的 值 设 置 为 2， 并 且 把 变更 提交 到 
# 目标 分 支 
success: 
gerrit: 
verified: 2 
submit: true 
# 任 一 带 有 voting 权限 的 任务 执行 失败 后 ， 把 Gerrit 上 的 Verified 的 值 设 置 为 -2 
failure: 
gerrit: 
verified: -2 
# 最 小 窗口 大 小 
window-floor: 20 
window-increase-factor: 2 


对 代码 清单 5-10 中 gate pipeline 的 一 些 重要 信息 说 明 如 下 : 
1) 使 用 依赖 型 pipeline， 优 先 级 为 high。 


2) 进入 pipeline 的 条 件 除了 check pipeline 使 用 以 外 ， 还 增加 了 如 下 约束 : Verified 标 签 存 在 来 自 于 用 户 名 包含 cibook 或 openzeroci 的 +1 或 +2 的 验证 结果 ， 同 时 Workf low 标 签 值 是 1; 结合 Gerrit 系 
统 中 每 个 标签 的 权限 都 是 受 控 的 ， 这 个 依赖 组 合 相对 来 说 比较 复杂 也 比较 严格 ， 这 也 正 是 Zuu| 严 格 把 关 的 体现 。 一 般 而 言 ， 只 有 CI 账号 返回 的 Verified 的 结果 才 是 可 信 的 、 有 效 的 ， 也 可 以 有 效 地 防止 误 操 
作 。 


3) 与 check pipeline 不 同 的 是 ，gate pipeline 一 般 都 是 只 由 comment 事 件 触发 。 比 如 : workflow 标 签 被 设置 为 1， 或 者 包含 用 户 名 为 cibook 或 openzeroci 的 用 户 把 Verified 标 签 设置 为 1。 
4) 注意 ， 在 pipeline 开 始 时 ，Verified 标 签 会 被 pipeline 重 置 为 0。 
5) 如 果 测 试 任务 执行 成 功 ， 那 么 pipeline 会 把 代码 提交 合并 到 主 分 支 。 下 面 来 看 一 下 post pipeline 的 实际 例子 ， 如 代码 清单 5-11 所 示 。 


代码 清单 5-11 Post pipeline 示 例 


- name: post 
# 独 字 型 的 pipeline 管理 器 
manager: IndependentpipelineManager 
Source: ge 


# 低 (lo a 

RUN Ced 

# Gerrit SERORS, 5 source 保持 一 至 
trigger: 

.gerrit: 


# ref-updated iM. H ref 是 包含 ^refs/heads/.*$ 正则 表达 式 
- event: ref-updated 
ref: ^refs/heads/.*$ 


从 代码 清单 5-11 中 可 以 看 到 ，post pipeline 监 听 ref-updated 消 息 ， 只 关心 Git 引 用 是 ref/head/ 相 关 的 变化 ， 亦 即 代码 合 入 到 目标 分 支 的 消息 。 这 可 以 用 于 文档 发 布 ， 以 及 触发 后 续 的 自动 化 安装 、 测 
试 和 部 署 等 流程 。 


56.2 Jobs 

job 是 layout.ym| 配 置 文件 中 的 可 选 部 分 ， 用 于 设置 任务 的 属性 ， 这 些 属 性 与 project 小 节 没有 相关 性 。 举 例 来 说 ， 一 个 任务 运行 失败 后 ， 和 希望 返回 自 定义 消息 ， 可 以 在 本 节 进 行 配置 ; 或 者 当 变 更 的 内 
容 满 足 一 定 的 条 件 时 才 触发 任务 的 执行 。 否 则 ， 如 果 没 有 配置 ，ZuuI 可 以 从 project 部 分 加 载 任务 相关 的 信息 。 

- name: Jenkins job 的 名 称 ， 该 名 称 参 见 4.1 节 详细 的 定义 。 该 字段 使 用 正则 匹配 ， 所 有 匹配 的 任务 都 会 应 用 该 规则 ， 必 须 存 在 。 本 节 除 name 外 的 所 有 其 他 字段 都 是 可 选 字段 。 


-queue-name: Zuul 会 把 多 个 使 用 相同 Jenkins 任 务 的 项 目 合并 ， 让 他 们 共享 依赖 型 Pipeline 管 理 器 。 给 这 些 队 列 进行 命名 ， 在 上 报 队 列 统计 数据 时 将 会 非 党 有用。 当然， 如 果 不 提 供 名 字 ，Zuul 会 自动 给 每 
个 队列 进行 命名 ， 但 这 个 名 字 将 会 非常 长 ， 而 且 会 根据 队列 中 的 项 目 变化 而 动态 修改 。 如 果 给 任务 指定 了 一 个 队列 名 称 ，Zuul 会 将 该 名 称 用 于 共享 队列 ， 而 不 是 自动 产生 一 个 新 的 。 如 果 有 多 个 任务 需要 使 
用 同一 个 共享 队列 ， 但 队列 的 名 称 不 同 ， 这 肯定 是 错误 的 配置 。 


: fallure-message: 同 pipeline 中 的 配置 。 
 success-message: 同 pipeline 中 的 配置 。 

: failure-pattern: 如 果 任务 执行 失败 ， 上 报 给 Gerrit 系 统 中 的 URL 的 格式 。 如 果 不 指定 ， 默 认 是 构建 URL 或 者 是 在 zuul.conf 中 定义 的 utl_pattern。 
“ success-pattern: 同 failute-battetn 。 


- hold-following-changes: 用 于 指示 依赖 型 pipeline 队 列 中 的 变更 是 否 需要 等 待 本 任务 成 功 执行 之 后 再 执行 其 他 任务 的 布尔 值 。 如 果 先 运行 一 个 时 间 非 常 短 的 任务 ， 但 该 任务 可 以 更 早 预测 一 个 需要 长 时 间 
运行 任务 的 失败 ， 这 毫 无 疑问 能 减少 Zuul 发 起 的 、 最 终 又 会 被 取消 的 任务 数目 。 在 这 种 场景 下 ， 少 量 的 短 任务 能 更 有 效 地 利用 测试 资源 。 另 一 方面 ， 如 果 把 这 种 机 制 用 在 一 个 需要 长 时 间 运 行 的 任务 上 ， 这 
将 使 得 Zuul 的 主要 特性 ， 并 行 测试 依赖 变更 的 目标 落空 ， 该 特性 需要 谨慎 使 用 。 


mutex: 从 名 称 上 可 以 看 出 该 字段 的 含义 ， 与 程序 语言 的 互 斥 量 是 相同 的 意思 。 这 是 任务 可 以 观察 的 一 个 字符 串 的 名 字 ， 同 一 时 间 ， 只 能 有 一 个 使 用 该 名 字 的 任务 进入 队列 。 注 意 ， 该 参数 作用 于 所 有 
的 pipeline。 


“ branch: 该 任务 在 什么 分 支 上 才 会 执行 ， 正 则 表达 式 参 数 。 


.skip-if: 在 所 有 可 选 参 数 都 满足 的 情况 下 ， 该 任务 就 不 会 被 执行 。 如 果 有 多 个 候选 集 ， 任 何 一 个 候选 集 满足 ， 该 任务 就 不 会 执行 。 在 一 个 项 目 有 多 个 子 目录 、 多 个 测试 任务 ， 并 且 当 测试 任务 只 与 部 分 
子 目 录 下 的 文件 有 关 ， 与 其 他 子 目录 下 的 文件 没有 关系 ， 该 参数 就 非常 有 用 ， 可 以 有 效 地 减少 并 发 测试 任务 的 数目 。 


- all-files-match-any: 一 个 正则 表达 式 列 表 ， 用 于 与 变更 相关 联 的 文件 名 进行 比较 。 如 果 一 个 变更 中 所 有 的 文件 名 都 至 少 满足 列表 中 一 个 表达 式 时 ， 则 认为 该 条 件 匹 配 。 其 中 /COMMIT_MSG 会 一 直 被 使 
用 ， 因 此 不 需要 包含 。 但 合并 的 提交 (merge commits) 是 个 例外 ， 即 使 /COMMIT_ MSG 不 匹配 ， 任 务 也 不 会 被 跳 过 。 如 果 是 合并 提交 ， 假 设 涉及 修改 的 文件 是 不 可 预测 的 ，CI 的 任务 必须 被 执行 。 


如 代码 清单 5-12 所 示 的 例子 ， 在 以 下 两 种 情况 下 ， 测 试 任务 被 忽略 
.openstack/neutton 项 目的 stable/juno 分 支 并 且 所 有 修改 的 文件 都 在 heuttonVtests 或 tools 子 目录 下 。 
: 所 有 修改 的 文件 都 在 doc 子 目录 下 或 者 都 是 以 tst 结 尾 的 文件 。 


代码 清单 5-12 Job skip-if 配 置 示例 


jobs: 
- name: r2 tempest-dsvm-neutron 
Skip-if 
# 如 果 是 openstack/neutron JH, HÆ  stable/juno 分 支 并且 
+ 所 有 修改 的 文件 都 在 ”neutron/tests HKE tools HXT 
# 那么 本 任务 就 不 会 被 执行 
- project: ^openstack/neutron$ 
branch: ^stable/juno$ 
all-files-match-any: 
- ^neutron/tests/.*$ 
- ^tools/.*$ 
# 如 果 所 有 修改 的 文件 都 在 ”goc 子 目 录 下 或 者 都 是 以 ”rst 结尾 的 文件 
# 那么 本 任务 就 不 会 被 执行 
- all-files-match-any: 
= ^doc/.*$ 
= NN ESUS 


Voting: 表示 该 任务 是 否 需 要 投票 的 布尔 值 ， 用 于 在 Gerrit 系 统 上 设置 Verified 标 签 的 值 。 
voting=true 
attempts: Zuul 尝 试 启动 一 个 任务 的 次 数 ， 如 果 该 次 数 达 到 ，Zuul 会 上 报 RETRY_LIMIT。 


attempts-3 


5.6.3 Projects 


本 小 节 的 参数 说 明 每 个 项 目 (对 应 3.2 中 的 repo 库 ) 在 每 个 pipeline 中 运行 哪些 任务 。 它 包含 一 个 列表 ， 如 代码 清单 ?-13 所 示 。 


代码 清单 5-13 Project 配置 示例 


- name: example/project 
check: 
* 4 project-merge 执行 成 功 后 ， 才 会 执行 其 他 3 个 任务 
- project-merge: 
- project-unittest 
- project-pep8 
- project-pyflakes 


gate: 
- project-merge: 
- project-unittest 
- project-pep8 
- project-pyflakes 


post: 
- project-publish 


- name: Gettit 中 tepo 库 的 名 称 。 

: merge-mode: 可 选 ， 当 把 变更 合并 到 目标 分 支 时 采用 的 策略 ， 支 持 以 下 的 取 值 : 

: merge-tesolve: 等 价 于 “git merge-s tfesolve”。 这 相当 于 当 Gettit 系 统 的 合并 模式 配置 为 尽 可 能 合并 并 且 自 动 解决 冲突 时 ，Gettit 系 统 对 一 个 项 目 所 进行 的 合并 操作 ， 这 也 是 默认 值 。 
: merge: 等 价 于 “git merge”。 

: cherry-pick: 等 价 于 “git cherry-pick” o- 


这 些 参数 后 面 就 是 前 面 定义 的 pipeline 的 引用 ， 如 果 该 pipeline 下 没有 任务 ， 那 该 pipeline 不 需要 被 引用 或 出 现 。 在 每 个 pipeline 的 配置 小 节 中 ， 列 出 每 个 需要 执行 的 任务 列表 。 如 果 某 个 测试 任务 名 称 
被 用 于 哈 希 字典 的 key (YML 语 法 ) ， 那 么 只 有 当 这 个 名 为 key 的 任务 执行 成 功 后 ， 其 他 任务 才 执行 。 在 上 面 的 例子 中 ， 只 有 当 project-merge 执 行 成 功 后 ， 任 务 project-unitest、project-pep8 和 project- 
pyflakes 才 会 被 执行 。 这 在 很 大 程度 上 可 以 避免 运行 一 些 无 用 的 任务 。 


其 中 noop 是 Zuul 内 置 的 一 个 特殊 任务 ， 它 永远 立即 返回 SUCCESS。 当 一 个 项 目 没 有 对 应 的 任务 ， 但 所 有 的 变更 都 希望 按 pipeline 进 行 处 理 时 ， 非 常 有 用 。 
下 面 以 openstack/nova 项 目 为 例 ， 代 码 清单 5-14 只 是 列 出 了 nova 项 目的 部 分 任务 。 


代码 清单 5-14 ”Openstack/nova 配 置 示 例 


- name: openstack/nova 
check: 
s gate-nova-tox-functional-ubuntu-trusty 
- gate-nova-tox-functional-ubuntu-xenial 
- gate-nova-tox-funct iona] -py35-ubuntu-xenial 
一 -F tempes ue s-ubuntu-trusty 
te-tempest-dsvm- ls-ubuntu-xenial 
& 一 般 来 说 ，gate pipeline 中 的 任务 是 check pipeline 的 一 个 子 集 ， 可 以 相同 
gate: 


- gate-nova-tox-functional-ubuntu-trusty 


gate-nova-tox-functional-ubuntu-xenial 
gate-nova-tox-functional-py35-ubuntu-xenial 
gate-tempest-dsvm-cells-ubuntu-trusty 
gate-tempest-dsvm-cells-ubuntu-xenial 


- nova-coverage-ubuntu-trusty 
- nova-coverage-ubuntu-xenial 


5.6.4 Project Templates 


当 有 许多 类 似 的 项 目 ， 比 如 插件 类 项 目 ， 希 望 使 用 相同 的 pipeline 和 配置 时 ， 可 以 采用 本 节 定 义 的 项 目 模 板 (project templates) 。 项 目 模板 定义 了 pipeline 以 及 运行 在 该 pipeline 中 的 任务 列表 。 对 于 
这 类 项 目 ， 直 接 引 用 该 项 目 模板 即 可 ， 比 较 容 易 进行 维护 和 更 新 。 


下 面 看 一 个 项 目 模板 定义 的 例子 ， 在 代码 清单 5-15 定 义 了 一 个 名 为 plugin-triggering 的 模板 ， 它 有 一 个 参数 jobpref ix, 


代码 清单 5-15 Project 模板 定义 示例 


project-templates: 
# 项 目 模板 名 称 
- name: plugin-triggering 
check: 
+ 可 以 有 参数 ， 如 ' {jobprefix}'， 也 可 以 是 没有 参数 的 任务 ， 如 'anteater' 
- '(jobprefix]-merge': 
- '(jobprefix]-pep8' 
- '(jobprefix]-pyflakes' 
- 'anteater' 


gate: 
- '(jobprefix]-merge': 
- '(jobprefixj-unittest' 
- '(jobprefix]-pep8' 
- '(jobprefix]-pyflakes' 
- 'anteater' 


在 需要 使 用 的 项 目 中 ， 直 接 引 用 即 可 ， 如 代码 清单 5-16 所 示 ， 项 目 plugin/foobar 使 用 了 plugin-triggering 模 板 ， 并 且 把 参数 jobpref ix 的 值 设置 为 plugin-foobar。 


代码 清单 5-16 ”Project 模 板 引 用 示例 


projects: 
- name: plugin/foobar 
template: 
- name: plugin-triggering 
# 传递 参数 jobprefix 的 值 为 plugin-foobar 
jobprefix: plugin-foobar 


一 个 模板 可 以 有 多 个 参数 ， 名 为 parameter 参 数 的 值 通过 展开 {parameten 宏 字符 串 来 使 用 。 参 数 name 自 动 提 供 并 包括 项 目的 名 称 ， 即 项 目 名 称 (project name) 中 /字符 后 面 的 字符 串 。 
一 个 项 目 也 可 以 组 合 使 用 多 个 项 目 模板 ， 所 有 这 些 项 目 模板 中 定义 的 任务 都 会 被 最 终 添加 到 该 项 目 中 。 当 然 ， 除 了 可 以 使 用 项 目 模板 外 ， 独 立 的 任务 也 可 以 添加 进来 一 起 使 用 。 


代码 清单 5-17 多 Project 模 板 引 用 示例 


projects: 
- name: plugin/foobar 
template: 
- name: plugin-triggering 
jobprefix: plugin-foobar 
- name: plugin-extras 
jobprefix: plugin-foobar 


check: 
- foobar-extra-special-job 


如 代码 清单 5-17 所 示 ， 项 目 plugin/foobar 使 用 了 两 个 模板 : plugin-triggering 和 plugin-extras， 以 及 一 个 名 为 foobar-extra-special-job 的 独立 任务 。 


项 目 中 这 些 任务 出 现 的 次 序 是 : 先是 项 目 模板 中 的 任务 ， 然 后 是 独立 任务 ， 来 自 于 项 目 模板 的 任务 与 在 项 目 模板 中 的 次 序 完 全 一 致 。 这 个 次 序 只 会 影响 Zuul 向 Gerrit 上 报时 ， 任 务 出 现 的 次 序 ， 没 有 其 
他 作用 ， 没 有 特殊 设置 的 情况 下 ， 这 些 任务 都 是 并 行 执行 的 。 


需要 注意 的 是 ， 如 果 项 目 引 用 了 多 个 项 目 模板 ， 并 且 多 个 项 目 模板 使 用 了 相同 的 任务 ， 或 项 目 本 身 也 直接 指定 了 该 任务 ， 最 后 一 个 引用 的 模板 或 项 目 指定 的 任务 具有 最 高 优先 级 。 


5.7 本章 小 结 


总 体 而 言 ，ZuuI 为 项 目 开 发 提供 了 一 个 有 效 的 门 控 系 统 ， 有 如 下 特点 : 
测试 后 合 入 ， 确 保 主线 稳定 。 

.并行 执行 ， 保 障 开 发 效率 。 

:自动 依赖 ， 保 证 结果 可 靠 。 

* 自动 回 滚 ， 尽 可 能 准确 、 自 动 化 、 并 行 编排 测试 任务 。 

项 目 依赖 ， 解 决 跨 项 目 集成 。 


` 通用 任务 ， 提 升 项 目 整体 基础 设施 维护 的 效率 。 


第 6 章 ”资源 管理 系统 (Nodepool) 


本 章 先 介绍 Nodepool 的 原理 和 相关 组 件 ， 然 后 结合 实践 讲解 如 何 配置 Nodepool， 由 于 Nodepool 使 用 了 镜像 制作 工具 ， 而 镜像 制作 在 OpenStack CIMCD 中 较为 关键 ， 所 以 接 下 来 会 单独 探讨 下 社区 镜 
像 制 作 工 具 及 其 大 致 原理 。 本 章 的 读者 需要 对 OpenStack 的 相关 概念 (如 租户 、FloatinglP、Region、AZ 等 ) 有 一 定 的 了 解 。 


6.1 Nodepool 简 介 


6.1.1 Nodepool 引 入 的 背景 
首先 ， 在 OpenStackCIl/CD 中 ， 所 有 的 变更 在 合 入 主 分 支 前 都 要 求 进行 单元 测试 、 集 成 测试 甚至 性 能 测试 ， 而 使 用 Zuul 作 为 门 控 系 统 后 ， 同 一 个 变更 的 同一 个 测试 也 可 能 需要 多 次 集成 测试 ， 这 些 测试 
需要 大 量 的 Slave 作 为 支撑 ， 所 以 如 何 有 效 管理 这 些 Slave 是 一 个 或 待 解决 的 问题 。 


其 次 ， 由 于 测试 用 例 的 多 样 性 ， 对 Slave 要 求 也 各 不 相同 ， 比 如 对 运行 在 Slave 上 的 操作 系统 有 的 要 求 Ubuntu、 有 的 要 求 CentOS,， 或 者 运行 操作 系统 的 种 类 相同 但 版 本 不 同 ， 或 者 仅仅 是 硬件 规格 不 一 
样 (有 的 是 CPU 密集 型 的 ， 要 求 CPU 资 源 较 多 ; 有 的 是 IO 密集 型 的 ， 对 内 人 存 或 磁盘 有 较 高 的 要 求 ) ; 更 为 普遍 的 情况 是 ， 硬 件 规格 要 求 一 样 ， 运 行 的 操作 系统 和 版 本 也 相同 ， 但 是 不 同 的 测试 依赖 的 软件 包 
可 能 不 一 样 : 容器 测试 一 般 需 要 Docker， 开 发 环境 有 的 需要 Python2 有 的 需要 Python3 等 。 如 何 定制 这 些 slave 以 满足 不 同 测试 的 需求 是 OpenStack CI/CD 要 解决 的 又 一 大 问题 。 


最 后 ， 对 于 同一 类 测试 ， 都 希望 运行 环境 尽 可 能 一 样 ， 这 意味 着 如 果 在 一 个 slave 上 多 次 运行 某 个 测试 ， 需 要 在 上 一 次 测试 运行 完毕 后 恢复 环境 ， 以 保证 下 次 测试 不 受 历史 数据 的 影响 ， 而 环境 的 清理 本 


身 就 不 是 一 件 容易 的 事 ， 有 时 其 处 理 逻 辑 的 工作 量 甚 至 会 超过 正常 业务 处 理 的 工作 量 ， 所 以 有 一 种 极端 的 做 法 就 是 运行 完 一 次 测试 ， 就 重新 装 一 次 系统 ， 这 显然 不 是 我 们 所 期 望 的 。 
为 了 解决 以 上 问题 ，Openstack 基 础 设施 团队 研发 了 Nodepool 系 统 ， 即 节点 资源 动态 管理 系统 ， 通 过 自动 定制 云 环境 中 的 虚 机 (VM) 来 满足 各 种 测试 对 运行 环境 的 要 求 ， 由 于 云 环 境 中 的 VM 易 于 管 


理 ， 可 以 根据 需要 ， 每 执行 完 一 次 测试 就 自动 重新 产生 一 个 全 新 的 VM 供 下 次 测试 使 用 ， 真 正 做 到 Slave 中 的 测试 彼此 间 相 互 不 影响 。 此 外 ，Nodepool 还 使 用 了 镜像 制作 工具 ， 来 满足 对 运行 环境 的 定制 化 


6.1 Nodepool 简 介 


6.1.1 Nodepool 引 入 的 背景 
首先 ， 在 OpenstackClMCD 中 ， 所 有 的 变更 在 合 入 主 分 支 前 都 要 求 进行 单元 测试 、 集 成 测试 甚至 性 能 测试 ， 而 使 用 Zuul 作 为 门 控 系统 后 ， 同 一 个 变更 的 同一 个 测试 也 可 能 需要 多 次 集成 测试 ， 这 些 测试 
需要 大 量 的 Slave 作 为 支撑 ， 所 以 如 何 有 效 管理 这 些 Slave 是 一 个 或 待 解决 的 问题 。 


其 次 ， 由 于 测试 用 例 的 多 样 性 ， 对 slave 要 求 也 各 不 相同 ， 比 如 对 运行 在 slave 上 的 操作 系统 有 的 要 求 UHbuntu、 有 的 要 求 CentOS， 或 者 运行 操作 系统 的 种 类 相同 但 版 本 不 同 ， 或 者 仅仅 是 硬件 规格 不 一 
样 (有 的 是 CPU 密集 型 的 ， 要 求 CPU 资 源 较 多 ; 有 的 是 IO 密集 型 的 ， 对 内 人 存 或 磁盘 有 较 高 的 要 求 ) ; 更 为 普遍 的 情况 是 ， 硬 件 规格 要 求 一 样 ， 运 行 的 操作 系统 和 版 本 也 相同 ， 但 是 不 同 的 测试 依赖 的 软件 包 
可 能 不 一 样 : 容器 测试 一 般 需 要 Docker， 开 发 环境 有 的 需要 Python2 有 的 需要 Python3 等 。 如 何 定制 这 些 slave 以 满足 不 同 测试 的 需求 是 Openstack CI/CD 要 解决 的 又 一 大 问题 。 


最 后 ， 对 于 同一 类 测试 ， 都 希望 运行 环境 尽 可 能 一 样 ， 这 意味 着 如 果 在 一 个 slave 上 多 次 运行 某 个 测试 ， 需 要 在 上 一 次 测试 运行 完毕 后 恢复 环境 ， 以 保证 下 次 测试 不 受 历史 数据 的 影响 ， 而 环境 的 清理 本 


身 就 不 是 一 件 容易 的 事 ， 有 时 其 处 理 逻 辑 的 工作 量 甚 至 会 超过 正常 业务 处 理 的 工作 量 ， 所 以 有 一 种 极端 的 做 法 就 是 运行 完 一 次 测试 ， 就 重新 装 一 次 系统 ， 这 显然 不 是 我 们 所 期 望 的 。 
为 了 解决 以 上 问题 ，Openstack 基 础 设施 团队 研发 了 Nodepool 系 统 ， 即 节点 资源 动态 管理 系统 ， 通 过 自动 定制 云 环境 中 的 虚 机 (VM) 来 满足 各 种 测试 对 运行 环境 的 要 求 ， 由 于 云 环 境 中 的 VM 易 于 管 


理 ， 可 以 根据 需要 ， 每 执行 完 一 次 测试 就 自动 重新 产生 一 个 全 新 的 VM 供 下 次 测试 使 用 ， 真 正 做 到 Slave 中 的 测试 彼此 间 相 互 不 影响 。 此 外 ，Nodepool 还 使 用 了 镜像 制作 工具 ， 来 满足 对 运行 环境 的 定制 化 


6.1.2 Nodepool 的 功能 


Nodepool 在 OpenStack CIMCD 中 的 位 置 如 图 6-1 所 示 。 
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图 6-1  Nodepool/E OpenStack CI/CD 中 的 位 置 


图 中 黑色 框 (加 粗 部 分 ) 里 面 即 Nodepool 包 含 的 范畴 ， 灰 色 (FRE) 部 分 为 其 他 组 件 。 从 Slave 和 Jenkins 交 互 的 角度 ，Slave 分 为 动态 Slave 和 静态 Slave。 静 态 Slave 需 要 手动 添加 到 Jenkins 中 ， 并 一 
直 存 在 于 Jenkins 中 ， 除 非 手动 从 Jenkins 中 删除 ， 静 态 Slave 可 以 是 物理 机 、 虚 机 或 容器 ; 动态 Slave 一 般 是 通过 自动 化 工具 管理 其 生命 期 的 ， 即 先 通过 工具 创建 Slave， 然 后 注册 到 Jenkins 中 ， 使 用 完毕 后 自 
动 从 Jenkins 中 删除 ， 动 态 Slave 目 前 多 以 虚 机 的 形式 存在 。 由 于 是 人 为 控制 ， 所 以 静态 slave 可 以 在 同一 个 生命 期 多 次 运行 测试 任务 ， 这 些 测试 可 能 相关 ， 也 可 能 不 相关 ， 而 动态 slave 是 按 自动 化 流程 控制 
各 生命 节点 的 ， 一 次 生命 期 只 运行 一 个 测试 任务 (Slave executors 默 认为 1) ， 任 务 运行 完 Slave 生 命 期 就 结束 了 ，Nodepool 系 统 就 是 这 样 的 Slave 生 命 期 自动 化 管理 工具 ， 其 与 Jenkins 和 Slave 的 关系 如 图 
6-2 所 示 。 
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图 6-2 Nodepool 与 Jenkins 和 Slave 的 关系 


需要 说 明 的 是 ，Nodepool 管 理 的 Slave， 不 仅 可 以 提供 独立 的 VM ， 还 可 以 是 一 组 VM ， 组 内 VM 彼 此 互通 ， 但 是 在 Jenkins 看 来 就 像 只 有 一 个 VM ， 这 种 情况 是 为 满足 一 次 测试 需要 多 个 VM 协同 工作 的 
复杂 场景 而 设计 的 。 例 如 测试 Kubernetes， 一 个 VM 用 作 kubernetes master， 其 余 作 kubernetes node, 


如 前 所 述 ， 当 前 Nodepool 仅 管理 VM ， 所 以 Nodepool 功 能 上 都 是 围绕 VM 而 来 的 ， 主 要 分 两 大 部 分 ， 如 下 所 述 。 
: VM 管理 相关 功能 
` 云 配 置 管理 : 对 接 一 个 或 多 个 云 环 境 。 
* VM 生命 期 管理 : 按照 配置 和 当前 Slave 使 用 情况 在 云 环 境 中 创建 VM， 使 用 完毕 后 删除 VM。 
Flavor 管 理 : 从 云 中 获取 Flavor 配 置 ， 并 在 创建 VM 时 根据 配置 选择 合适 的 Flavor。 
: FloatingIP 管 理 : 从 云 环境 中 为 VM 分 配 FloatingIP， 便 于 外 部 访问 VM，VM 删 除 时 释放 FloatingIP。 
Slave 注册 注 销 管理 : 将 云 中 分 配 到 的 VM 通 过 RESTful 接 口 注册 到 Jenkins 中 ， 作 为 Jenkins 的 Slave， 使 用 完毕 后 从 Jenkins 中 注销 。 
. 资源 同步 : 同步 云 环境 中 的 VM 和 供 Jenkins 使 用 的 VM， 保 持 资源 的 一 致 性 ， 防 止 VM、FloatingIP 等 资源 的 漏 删 。 
“ 镜像 管理 相关 功能 
- 制作 镜像 : 根据 Nodepool 镜 像 配置 需求 定制 镜像 。 
" 上 传 镜像 : 将 定制 好 的 镜像 上 传 到 云 环 境 ， 供 动态 创建 VM 时 使 用 。 


. 清理 镜像 : 镜像 文件 在 Nodepool 上 有 缓存 ，Nodepool 周 期 性 清理 本 地 过 期 不 用 的 镜像 文件 ， 为 新 的 镜像 保留 足够 的 空间 。 


6.2” 安 六 Nodepool 


Nodepool 是 一 个 复杂 的 系统 ， 其 运行 需要 多 个 外 部 服务 的 支撑 ， 本 节 先 简要 说 明 Nodepool 依 赖 外 部 服务 的 安装 ， 然 后 再 介绍 Nodepool 的 安装 。 


6.2.1 ”准备 外 部 依赖 服务 


Nodepool 依 赖 的 外 服 服务 主要 有 数据 库 、Zookeeper、Gearman 和 ZeroMQ 等 I1， 这 些 服 务 的 安装 配置 在 此 只 做 简单 说 明 ， 更 详细 的 过 程 请 参见 各 服务 对 应 的 官网 资料 。 


1 数据 库 


接收 来 自 于 Nodepool 的 高 并 发 请 求 ， 不 推荐 使 用 SQLite。 如 非特 殊 说 明 ， 本 文 后 面 数据 库 指 的 都 是 MySQL。 


由 于 每 创建 或 者 删除 一 个 Slave， 都 会 新 建 一 个 数据 库 的 连接 ， 所 以 数据 库 连 接 数 至 少 要 大 于 期 望 使 用 slave 个 数 的 两 倍 ， 下 面 是 数据 库 连 接 数 参数 的 配置 示例 ， 如 代码 清单 6-1 所 示 。 


代码 清单 6-1 设置 MySQL 的 最 大 连接 数 


mysg show global variables like "%max connection$"; 


1 row in set (0.00 sec) 


mysql» set global max connections-200; 


mysql» show global variables like "$max connection$"; 


1 row in set (0.00 sec) 


用 户 需要 手动 创建 数据 库 ，Nodepool 连 上 对 应 数据 库 后 会 自动 创建 需要 的 表 信 息 ， 如 代码 清单 6-2 所 示 。 


代码 清单 6-2 ”创建 并 给 本 地 用 户 授权 


CREATE USER 'nodepool'G'localhost' IDENTIFIED BY '<password>'; 
CREATE DATABASE nodepool; 
GRANT ALL ON nodepool.* TO 'nodepool'G'localhost'; 


如 果 将 数据 库 安 装 在 独立 的 节点 上 ， 需 要 允许 数据 库 远 程 访问 ， 如 代码 清单 6-3 所 示 。 


代码 清单 6-3 ”授权 给 远程 用 户 访问 


CREATE USER 'nodepool'G'$' IDENTIFIED BY '«password»'; 
GRANT ALL ON nodepool.* TO 'nodepool'Q'£'; 


Nodepool 连 接 上 数据 库 后 ， 创 建 数据 库 的 结果 如 代码 清单 6-4 所 示 。 


代码 清单 6-4 Nodepool 数 据 库 表 


mysql» show tables; 


node 


2.Zookeeper 


Zookeeper 在 Nodepool 中 用 来 存储 镜像 信息 。 单 实例 Zookeeper 可 以 与 Nodepool 部 署 在 一 起 ， 如 果 Nodepool 需 要 管理 的 镜像 比较 多 ， 此 时 Nodepool 本 身 消 耗 的 资源 会 较 大 ， 为 了 避免 Nodepool 
和 Zookeeper 相 互 影响 ， 应 该 将 Zookeeper 配 置 成 独立 的 节点 或 集群 。 如 果 选 择 集 群 ， 一 般 包 含 3 个 Zookeeper 节 点 就 足够 了 。 


Zookeeper 的 安装 及 配置 请 参见 第 9 章 。 对 于 Nodepool， 只 需要 配置 Zookeeper 的 服务 器 地 址 ，Nodepool 连 接 上 Zookeeper 后 会 自动 创建 需要 的 Znode 节 点 信息 ， 如 代码 清单 6-5 所 示 。 


代码 清单 6-5 ”Zookeeper 中 的 Nodepool 部 分 结构 


[zk: localhost:2181(CONNECTED) 0] 1s / 

[nodepool, zookeeper] 

[zk: localhost:2181(CONNECTED) 1] ls /nodepool 

[images] 

[zk: localhost:2181(CONNECTED) 2] ls /nodepool/images 

unu trusty-large, ubuntu-trusty] 

[zk: localhost:2181(CONNECTED) 3] ls /nodepool/images/ubuntu-trusty 
builds] 

http: //www.hzcourse.com/resource/readBook?path-/openresources/teach ebook/uncompressed/17933/OEBPS/Text/.. 
es à 

Quse 


ubuntu-ttrusty-latge 和 ubuntu-ttrusty 是 作者 环境 中 的 配置 ， 实 际会 根据 Nodepool 中 label 的 配置 不 同 而 有 所 差异 。 
3.ZeroMQ 


Nodepool 通 过 ZeroMQ 从 Jenkins 接 收 Slave 的 状态 通知 信息 。Jenkins 服 务 器 通过 插件 的 方式 来 支持 ZeroMQ，Jenkins 揪 件 的 具体 安装 请 参见 第 4 章 中 的 描述 。Nodepool 需 要 配置 ZeroMQ 的 地 址 ， 
并 确保 Nodepool 可 以 正确 连接 到 Jenkins 服 务 器 中 指定 的 端口 。 


4.Gearman 


Nodepool 在 创建 Slave 时 ， 可 能 需要 从 Zuul 和 Jenkins 中 获取 Slave 的 当前 使 用 情况 ， 这 些 是 通过 Gearman 进 行 的 ，Gearman 可 以 使 用 Zuul 自 带 的 服务 (参见 第 5 章 ) ， 也 可 以 使 用 独立 的 Gearman 服 
务 (参见 第 9 章 ) 。 需 要 说 明 的 是 ，Nodepool 也 可 以 在 不 使 用 Gearman 的 情况 下 工作 ， 此 时 工作 在 “节点 替代 模式 ”， 即 Nodepool 只 有 在 删除 一 个 Slave 时 才 创 建 一 个 新 的 Slave， 而 不 会 提前 创建 
Slave。 不 过 ， 一 旦 配置 了 Gearman， 请 确保 Nodepool 和 Gearman 是 可 以 通信 的 ， 否 则 Nodepool 不 能 正常 工作 。 


可 以 通过 gearadmin--status 或 gearadmin--workers 查 看 Nodepool 和 Gearman 工 作 是 否 正 常 ， 如 代码 清单 6-6 所 示 。 


代码 清单 6-6 ”查看 gearman 状 态 


root@common:~# gearadmin --status 
build:zaas-docbuild-rst:ubuntu-trusty 0 0 13 
build:openzero-blackduck-scan-query:ubuntu- -trusty 0 0 13 
build:knitter exec build:K8S-CI build 0 0 1 
build:salt-formula-kubernetes-real-update:ubuntu-trusty-large 0 0 8 


p " 
ETE 


以 上 信息 的 含义 请 和 参见 第 9 章 中 Gearman 的 相关 介绍 。 
5.Sstatsd 和 Graphite 


该 配置 是 可 选 的 ，Statsd 负 责 收集 并 合并 测量 值 信息 ， 


是 Nodepool 中 部 分 测量 信息 


测量 项 
nodepool.nodes.STATE 


nodepool.target. TARGET.nodes.S TATE 
nodepool.label.LABEL.nodes. STATE 
nodepool.provider.PROVIDER.nodes.STATE 


nodepool.launch.provider.PROVIDER.subkey 


nodepool.launch.image. IMAGE .subkey 


nodepool.launch.subkey 


[1] https:/ /docs.openstack.org/infra/nodepool/installation.html o 


6.2.2 ”安装 Nodepool 


安装 和 配置 好 Nodepool 的 外 部 依赖 后 ， 就 可 以 安装 Nodepool 服 务 了 ，Nodepool 需 要 Python2.7 或 更 新 版 本 。 


使 用 git 通 过 源码 方式 安装 : 


表 6-1 


Nodepool 中 的 部 分 


然后 将 这 些 处 理 后 的 测量 信息 传 给 Graphite， 后 者 以 时 间 序 列 为 依据 存储 数据 ， 并 绘制 图 表 。 如 果 已 经 有 一 个 Statsd&-Graphite 系 
统 ，Nodepool 也 可 以 直接 与 其 进行 集成 ， 用 于 采集 Slave 和 镜像 使 用 情况 。 配 置 时 ， 通 过 设置 环境 变量 STATSD_HOST 为 Statsd 的 域名 ， 


测量 信息 


说 明 

点 状态 (如 ready, deleting, used 等 ) 
Jenkins 下 的 方太 状态 
标签 下 的 市 点 状态 
云 环 境 下 的 节点 状态 
云 环境 下 的 附加 状态 信息 ( 
Lk PP 的 附加 状态 信息 

点 尼 动 的 附加 状态 信息 


(如 error 信息 


设置 STATSD_ PORT 为 Statsd 的 端口 (默认 为 8125) 。 


表 6-1 所 示 的 


git clone https://github.com/openstack-infra/nodepool.git 
cd nodepool && git checkout 0.5.0 
pip install . 


Qu 


当前 Nodepool 最 新 的 版 本 只 支持 Zuulv3， 相 关 架 构 和 之 前 版 本 不 兼容 ， 所 以 推荐 使 用 源码 方式 安装 (tag 0.5.0 之 后 的 都 是 支持 Zuulv3 特 性 ， 所 以 需要 检 出 tag 0.5.0 或 之 前 的 版 本 ) o 


成 功 安装 完 Nodepool 后 ， 要 使 系统 能 正常 运行 ， 还 


6.3 ”Nodepool 的 设计 原理 


Nodepool 系 统 框架 及 与 其 他 系统 的 关系 如 图 6-3 所 示 。 


Nodepool 包 括 Nodepoold、Nodepool-pbuilder 和 Nodepool Client 


: Nodepoold: 资源 管理 守护 进程 ， 简 称 资 


ZINELA 
一 “| pb 刀 。 


区 源 管理 ， 包 括 从 配置 的 OpenStack 环 境 中 创建 和 删除 VML， 


需要 对 Nodepool 做 诸多 的 配置 ， 为 了 理解 各 个 配置 的 意义 ， 我 们 需要 先 介绍 Nodepool 的 相关 设计 原理 。 


以 及 将 VM 从 Jenkins 中 注册 注销 等 。 


Jenkins 


NodePool-builder 


Nodepool Client 


OpenStack 


图 6-3  Nodepool Z& 44 
: Nodepool-builder: 镜像 管理 守护 进程 ， 简 称 镜像 管理 ， 负 责 镜 像 的 制作 和 上 传 。 
: Nodepool Client: Nodepool 客 户 端 ， 对 外 提供 多 种 CLI， 包 括 VM、Job 和 镜像 的 增 、 删 、 查 等 。 


OpenStack CI/CD 中 ， 与 Nodepool 有 交互 的 主要 外 部 组 件 有 Jenkins 和 Zuul， 以 及 提供 Slave 运 行 环境 的 OpenStack。 除 此 之 外 ， 为 了 实现 Nodepool 上 下 文 信息 的 持久 化 ， 需 要 数据 库 来 保存 已 创建 
VM 的 信息 。Nodepool-builder 是 一 个 CPU 和 1O 密 集 型 的 服务 ， 且 需要 访问 internet， 为 了 减少 对 Nodepool 其 他 服务 的 影响 ， 设 计 上 将 Nodepoold 和 Nodepool-builder 进 行 解 厢 ， 两 者 可 以 分 别 部 署 到 
不 同 的 服务 器 上 ， 通 过 Zookeeper 进 行 镜像 配置 信息 交互 。 


Nodepool 内 外 部 涉及 的 组 件 、 模 块 及 其 功能 和 通信 方式 如 表 6-2 所 示 。 


表 6-2 Nodepool 内 外 部 组 件 、 模 块 及 其 通信 方式 


Nodepool 组 件 其 他 组 件 通信 方式 说 明 


注册 VM 
Nodepoold Jenkins RESTful NE 
注销 VM 


Nodepoold | Jenkins ^ — | ZeoMQ 广播 VM 状态 


Nodepoold 获取 VM 使 用 状态 


创建 VM 
删除 VM 
Nodepoold d OpenStack RESTful 查询 VMs 
查询 Flavor 
创建 FloatingIP 
删除 FloatingIP 


Nodepool-builder OpenStack RESTful 上 传 镜像 


Nodepool 组 件 其 他 组 件 通信 方式 说 明 
Nodepooid TK EWEEIY: 
Nodepoold WMT EVM EE 


查 / 删 VM 信息 


Nodepoold < 一 > Nodepool Client sql Zookeeper 
P p 4 P 增 / 查 / 删 镜像 信息 


Nodepool 
Client 


Nodepool-builder 一 > Zookeeper 查询 镜像 信息 


面 分 别 详细 介绍 Nodepool 的 各 个 部 分 。 


6.3.1 资源 管理 (Nodepoold) 


资源 管理 也 是 Nodepool 的 主体 ， 按 照 功能 分 为 调度 、 节 点 启动 器 (NodeLauncher) 、 节 点 删除 器 (NodeDeleter) 和 周期 性 校 验 及 检查 等 几 个 部 分 。 
- 调度 模块 (NodePool) : 动态 获取 云 配 置 、Jenkins 配 置 、 数 据 库 配置 、Gearman 配 置 、Zookeepet 配 置 等 ， 并 负责 启动 NodeLauncher。 
: NodeLauncher: 从 云 环境 中 分 配 VM， 进 行 相关 的 配置 (如 分 配 Floating[P 和 注入 脚本 等 ) 后 将 VM 注册 给 Jenkins。 


: NodeDeleter: 接收 Jenkins 的 通知 ， 将 VM 从 Jenkins 中 注销 ， 并 将 其 从 对 应 的 云 环境 中 删除 


站 
bld | | watch 
十 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 -+ reg | | trigger 
iINodepoo L-builderi—————- * | d—— * 
qun ——— | | Jenkins | 
| 十 一 一 一 十 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 十 
| a 
| | Inform/Notify 
| | 
让 一 一 一 一 一 一 一 VW 一 一 一 一 一 一 一 十 | 
| 忆 一 一 一 一 一 一 一 十 
4---—-----»  NodePool <==- 
| 十 一 一 一 十 十 一 一 一 十 | 
| | | | | | 
| oe | | 
H | | | | 
= done | | start/del | start/del | | done 
| | vms vms | | 
| | | 
| | | 
+ 一 一 一 一 一 一 一 一 一 VY 一 一 一 一 十 + 一 一 一 Y 一 一 一 一 一 一 一 一 一 一 十 
| NodeLauncher | | NodeLauncher | 
-— 一 一 一 一 一 一 一 一 一 十 十 一 十 一 一 一 一 一 一 一 一 一 一 一 一 一 一 十 


| NodeDeleter | 


十 一 十 一 一 一 一 一 一 一 一 一 一 一 个 


| NodeDeleter | 


十 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 十 
| Openstack | 
MM — 


图 6-4 ”Nodepool 创 建 VM 的 主要 流程 


: 周期 性 检测 到 VM 的 网 络 连接 ， 如 果 发 现 和 VM 网 络 不 可 达 则 认为 VM 不 能 对 外 提供 服务 ， 便 将 其 从 Jenkins 和 云 环 境 中 删除 ， 并 申 


资源 管理 的 主要 工作 流 如 图 6-4 所 示 。 

过 程 简 述 如 下 : 

1) 以 下 情况 只 要 任何 一 个 出 现 ， 都 会 触发 Nodepool 创 建 VM : 
: 配置 变更 导致 需要 的 Slave 数 增加 。 
. 通过 Nodepool Client 触 发 新 建 VM。 


Jenkins 消 耗 了 Slave 而 需要 补充 新 的 Slave。 


青 新 的 VM 取代 之 。 周 期 性 检查 主要 负责 清除 历史 遗留 的 VM。 


2) NodeLauncher 根 据 配置 选择 合适 的 云 ， 使 用 最 新 的 镜像 创建 YM， 并 设置 供 外 部 访问 的 Float-inglP， 然 后 注册 给 Jenkins 用 作 Slave。 


3) Jenkins 运 行 完 测试 任务 后 ， 通 过 ZeroMQ 广 播 Slave 已 使 用 完毕 。 


4) NodeDeleter 收 到 广播 消息 后 调用 Jenkins 提 供 的 RESTful 接 口 从 Jenkins 中 注销 Slave， 并 从 云 环境 中 删除 对 应 的 VM 和 FloatinglP。 


Que 


创建 VM 过 程 中 涉及 的 细节 : 例如 ， 如 何 选 择 云 、 如 何 选 择 VM 的 规格 、 需 要 产生 多 少 VM、 如 何 命名 VM 等 ， 将 在 6.4 节 讲解 。 


以 上 过 程 周而复始 ， 始 终 保持 Jenkins 中 的 Slave 数 为 配置 中 定义 的 数目 。 需 要 说 明 的 是 ， 在 VM 启动 成 功 后 ， 且 在 注册 到 Jenkins 前 ， 可 以 根据 需要 ， 自 定义 脚本 对 VM 做 一 些 初始 化 或 测试 等 操作 ， 只 
有 这 些 操作 成 功 后 才 会 注册 到 Jenkins， 否 则 认为 创建 失败 。 


另外 ， 对 于 多 节点 模式 ， 即 一 次 创建 多 个 VM， 这 些 VM 形 成 一 个 组 为 一 次 测试 服务 ， 则 其 中 一 个 VM 作为 主 节点 ， 其 余 VM 作 为 子 节点 ， 且 只 有 主 节点 信息 会 注册 到 Jenkins， 子 节点 对 Jenkins 不 可 见 。 
这 种 情况 的 一 个 应 用 场景 是 : 对 Kubernetes 进 行 功 能 测试 ， 主 节点 作为 Kubernetes master， 子 节点 作为 Kubernetes node。 为 了 方便 运行 在 该 组 中 的 测试 任务 知道 这 是 一 个 VM 组 (如 : Kubernetes 
node 需 要 知道 Kubernetes master 的 地 址 ) ， 节 点 创建 时 Nodepool 会 在 该 组 所 有 节点 中 注入 下 列 信息 到 固定 的 文件 中 。 


: /etc/nodepool/role: 本 节点 的 角色 ， 取 值 primary 或 者 sub， 表 明 是 主 节点 还 是 子 节 点 ， 只 有 主 节 点 会 注册 到 Jenkins 中 。 
/etc/nodepool/node: 本 节点 的 FloatingIP 地 址 ， 用 于 云 外 部 访问 本 节点 。 

- /etc/nodepool/node_private: 本 节点 的 fxedIP 地 址 ， 即 租户 内 的 IP， 用 于 组 内 节点 彼此 间 访 问 ， 该 IP 对 云 外 不 可 见 。 

: /etc/nodepool/primaty node: 主 节点 的 FloatingIP 地 址 ， 主 节点 上 该 值 和 /etc/nodepool/node 相 等 。 

- /etc/nodepool/primary_node_private: 主 节点 的 fixedIP 地 址 ， 主 节点 上 该 值 和 /etc/nodepool/node_private 相 等 。 

: /etc/nodepool/sub nodes: 所 有 子 节点 的 FloatingIP 地 址 ， 如 果 包 含有 多 个 子 节点 ， 则 每 个 子 节点 占 一 行 。 

- /etc/nodepool/sub, nodes private: 所 有 子 节点 内 部 的 fixedIP 地 址 ， 如 果 包 含有 多 个 子 节点 ， 则 每 个 子 节点 占 一 行 。 

: /etc/nodepool/id rsa: 为 该 组 VM 产生 的 OpenSSH 私 钥 ， 对 应 公 角 为 /etc/nodepool/id_rsa.pub， 用 于 VM 组 内 彼此 间 加 密 通 信用 。 
: /etc/nodepool/id rsapub: 为 该 组 VM 产生 的 OpenSSH 公 和 钥 ， 对 应 私 钥 为 /etc/nodepool/id_rsa， 用 于 VM 组 内 玻 此 间 加 密 通 信用 。 
“ /etc/nodepool/provider: 该 组 VM 所 在 的 云 信 息 ， 主 要 包括 如 下 几 项 : 

: NODEPOOL PROVIDER: VM 云 提 供 商 的 名 字 。 

: NODEPOOL CLOUD: VM 所 处 云 的 名 称 。 


: NODEPOOL REGION: VM 所 处 的 Region。 


. NODEPOOL AZ: VM 所 处 的 available zone。 
: /etc/nodepool/uuid: VM 在 云 中 的 ID， 用 于 唯一 标识 该 VM。 
基于 以 上 信息 ， 可 以 为 Slave 组 织 较 为 复杂 的 测试 场景 ， 满 足 特有 的 测试 运行 需求 。 
为 了 便于 Nodepool 对 VM 进行 有 效 的 管理 ， 在 创建 时 ，Nodepool 会 为 YM 添加 一 些 元 数据 信息 : 
` groups: 基于 ]Json 编 码 的 列表 ， 包 含 创建 VM 时 使 用 的 镜像 名 称 ， 云 提供 商 的 名 字 等 。 
: nodepool: 基于 Json 编 码 的 字典 ， 包 含 创建 VM 时 使 用 的 镜像 名 称 ， 云 提供 商 的 名 字 ， 以 及 唯一 标识 Nodepool 的 node_id 等 。 


下 面 是 元 数据 在 云 中 显示 例子 ， 如 图 6-5 所 示 。 


Metadata 


Key Name None 


Image Name .— template-ubuntu-trusty-1516296901 
Image ID — b35ac6e2-fe13-4446-a376-a453d5b50ab7 
groups 


图 6-5 ”Nodepool 创 建 的 VM 元 数据 


6.3.2 ”镜像 管理 (Nodepool-builder) 


镜像 管理 主要 分 为 四 个 部 分 : 镜像 调度 (NodePoolBuild) 、 镜 像 制 作 (BuildWorker) 、 镜 像 上 传 (UploadWorker) ， 以 及 镜像 清理 (CleanupWorker) 。 顾 名 思 义 ，BuildWorker 主 要 作用 是 根 
据 配 置 动态 生成 创建 VM 需要 的 镜像 文件 ，UploadWorker 将 BuildWorker 制 作 好 的 镜像 上 传 到 云 环境 中 。NodePoolBuild 负 责 整个 镜像 的 配置 、 制 作 和 上 传 的 调度 管理 ， 从 命名 上 也 可 以 看 
出 ，BuildWorker 和 和 UploadWorker 都 可 以 配置 为 多 实例 的 方式 ， 以 提高 处 理 效 率 ， 默 认 BuildWorker 运 行 1 份 ，UploadWorker 运 行 4 份 。Nodepool 是 一 个 独立 的 系统 ， 在 镜像 上 传 到 云 环境 后 ， 都 会 在 本 
地 保留 当前 正在 使 用 的 镜像 ， 另 一 方面 ， 镜 像 制 作 自 身 也 会 留 下 大 量 的 临时 文件 ， 如 果 不 加 以 清理 将 会 对 存储 带 来 较 大 的 压力 ， 这 就 是 CleanupWorker 引 入 的 原因 ，CleanupWorker 会 定期 扫描 镜像 缓存 
目录 和 镜像 存储 目录 ， 对 超期 文件 进行 清理 。 


前 面 介绍 架构 时 已 经 提 及 ，Nodepool-builder 和 Nodepool 是 松 厅 合 的 ， 为 了 获得 较 高 的 效率 ， 可 以 将 Nodepool-builder 部 署 到 不 同 的 服务 器 上 ， 多 实例 条 件 下 Nodepool-builder 彼 此 独立 ， 通 过 
Zookeeper 和 Nodepool 交 换 镜像 信息 ，Nodepool 中 Zookeeper 的 配置 树 结构 如 图 6-6 所 示 。 


Nodepool 


images 


[image name-a] [image name-b] 


builds S builds-request 


图 6-6 ” Zookeeper 中 Nodepool 的 存储 结构 


图 6-6 中 的 image name-a 和 image name-b 代 表 需 要 Nodepool-builder 制 作 的 镜像 或 者 已 经 制作 的 镜像 标签 名 称 ，request-build 表 明 当 前 需要 制作 image name-a， 当 前 制作 的 最 新 序号 是 build- 
no2; 对 于 制作 的 镜像 image name-a， 会 上 传 到 两 打 云 中 ， 分 别 是 provider name-x 和 provider name-y， 其 中 provider name-y 中 对 镜像 image name-a 进 行 了 两 次 上 传 ， 上 传 序号 分 别 是 image-no1 和 
image-no2。 对 于 制作 的 镜像 ，Nodepool-builder 都 只 保留 最 近 成 功 的 2 个 ， 而 对 于 上 传 的 镜像 ， 只 在 每 个 云 环境 下 保留 1 个 成 功 的 (如 出 现 多 个 上 传 节 点 说 明 曾 经 上 传 失败 过 ) ， 其 他 的 都 会 被 Cleanup- 
Worker 删 除 (前 面 已 经 说 明 ，Nodepoo| 每 次 在 新 建 VM 时 ， 总 是 使 用 对 应 云 环境 下 最 新 的 镜像 ) ， 这 意味 着 某 个 镜像 在 某 个 云 环 境 下 最 多 存在 1 个 镜像 文件 。 无 论 是 制作 镜像 、 上 传 镜像 还 是 清理 历史 镜 


介绍 完 ZooKeeper 中 的 节点 结构 后 ， 我 们 看 下 镜像 管理 的 主要 工作 流 ， 如 图 6-7 所 示 [1]。 


十 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 十 
| ZooKeeper | 


ert] n n á— n — 
i | 
bld | | watch 
4---——---—————4 req | | trigger 
| client 二 一 一 -一 一 + | t+ 
3 | | NodepoolBuilderApp | 
| m 
| 
| 
| 


十 一 一 一 -一 一 V 一 -一 十 | 
| «———-——- = 
*———----» NodePool ae 中 
| +—— Builder | | 
| | | | | | 
| 1 mM — | | 
| | | | 
done | | start start | | done 

| | bld upld | | 
| | | | 
| | | | 

+N 十 -一 一 一 一 一 一 一 一 十 

| BuildWorker | | UploadWorker | 

十 一 十 一 一 一 一 一 一 -一 一 一 十 + 一 一 一 一 一 一 一 一 一 一 一 一 一 一 十 

| Buildworker | | UploadWorker | 
十 一 一 一 一 一 一 一 一 -一 上 一 一 一 一 -一 一 一 一 一 一 十 
| BuildWorker | | pu— | 
一 一 一 一 一 一 一 一 一 一 一 一 一 一 十 十 一 一 一 一 一 一 一 一 一 一 一 一 一 一 十 
图 6-7 镜像 制作 主要 流程 
过 程 简 述 如 下 : 
1) 有 三 种 情况 会 触发 镜像 制作 : 镜像 配置 友 生 变更 、 客户 端 触 友 ， 或 者 镜像 超过 了 生存 期 此 时 会 在 Zookeeper 树 结构 中 对 应 的 镜像 标签 下 创建 builers-request 节 点 ， 表 明 该 镜像 需要 制作 。 


2) 处 于 守护 状态 的 某 个 BuildWorker 读 取 builers-request， 会 首先 加 上 制作 锁 ， 并 生成 新 的 制作 序号 ， 在 对 应 label 的 builds 节 点 下 创建 制作 新 节点 如 build-no2。 在 此 过 程 中 如 果 其 他 BuildWorke[ 扫 


描 到 builers-request 的 存在 ， 会 因为 得 不 到 锁 而 不 会 导致 镜像 重复 制作 。 


3) 得 到 锁 的 BuildWorker 读 取 镜 像 的 具体 配置 (主要 是 制作 镜像 用 的 Elements 和 镜像 类 型 等 ) ， 调 用 disk-image-builder 工 具 生 成 镜像 ， 成 功 后 将 节点 状态 设 为 ready， 释 放 制 作 锁 ， 并 删除 builers- 


4) 同样 处 于 守护 状态 的 某 个 UploadWorker 检 测 到 有 新 的 镜像 制作 完毕 后 ， 会 扫描 Zookeeper 中 需要 该 镜像 的 云 所 对 应 节点 (如 provider name-y) 下 是 否 包 
锁 ， 在 云 节 点 的 images 下 创建 新 的 上 传 节 点 (如 image-no2) ， 然 后 将 镜像 上 传 到 对 应 云 环境 下 ， 成 功 后 将 新 创建 节点 状态 设 为 ready， 最 后 释放 上 传 锁 。 


含 该 镜像 的 信息 


， 如 果 没 有 则 会 获取 上 传 


在 创建 制作 镜像 节点 build-no2 和 上 传 镜 像 节 点 image-no2 时 ，BuildWorker 或 Upload-Worker 都 会 获取 当前 已 经 存在 的 节点 序号 ， 保 证 每 次 创建 的 序号 都 是 最 新 的 。 为 了 便于 管理 和 区 别 于 云 中 的 其 


他 镜像 ，Nodepool-builder 对 上 传 到 云 中 的 镜像 也 设 有 单独 的 元 属性 ， 主 要 是 制作 序号 和 上 传 序号 ， 如 图 6-8 所 示 的 是 镜像 属性 在 云 中 的 显示 示例 。 


Custom Properties 


direct url — rbd://bBa0778d-44b7-4B6ed-a7c7- 
bai /&fü43b3a/images/b95ac6e2-fae13-4446-a376- 
ad453d5b50ab//snap 

file — /v2/images/b95ac6ez-fe13-4446-a3/6- 
ad53d5b50ab//file 
Tags 

locations — [l'url :"rbd://bBa0778d-44b7-45ed-a?c?- 
ba176f043b3a/images/b85ac68a2-f1ae13-4446-a376- 
ad53d5b50ab7/snap", "metadata" :人 

owner specified.shade....  1132aadáldcOafe7011c33tb42d8e86adf23c32af883b4 1 d81182d9d028cfcb8 
2odepool upload id 0000000001 


owner specified.shade....  images/template-ubuntu-trusty-1516296901 
Virtual Size 
owner specified.shade....  Íí26ab7975b5154ac4317f775883b5c13 
schema  /v2/schemas/image 


图 6-8 Nodepool 镜 像 的 属性 


[1] https:/ /docs.openstack.org/infra/nodepool/devguide.html o 


6.3.3 Fg (Nodepool Client) 


ZAE ACHIA, JAPART —"MESPROSJUNodepooliSzEEz, CUREA 12108643 29Bo HEX, VMX., SRREGERUODIBXESSJVNBEA. mIPuSEL EUSEB UBER X, RH 
中 和 VM 相关 的 子 命令 操作 和 Job 相 关 的 操作 是 通过 数据 库 和 Nodepoold 交 互 处 理 的 ， 而 和 镜像 相关 的 操作 是 通过 Zookeeper 和 Nodepool-builder 一 起 协作 处 理 的 [1], 


1. 配 置 相关 操作 命令 


和 配置 相关 的 只 有 一 个 命令 ， 即 config-validate， 该 命令 校 验 当前 配置 是 否 正确 ， 如 果 校 验 失败 会 给 出 错误 信息 。 一 般 在 修改 配置 后 ， 都 可 以 通过 该 命令 进行 预 检查 。 该 命令 用 法 如 代码 清单 6-7 所 


代码 清单 6-7 ”config-validate 示 例 


nodepool@nodepool:~$ nodepool config-validate -c /home/nodepool/nodepool.yaml 
2018-03-31 17:43:57,149 INFO nodepool.cmd.config validator: validating /home/nodepool/ 
—nodepool.yaml 
2018-03-31 17:43:57,178 INFO nodepool.cmd.nodepoolcmd: Configuation validation 
—Vcomplete 


其 中 -c 指 明了 需要 校 验 的 配置 文件 ， 这 是 Nodepool 客 户 端 通用 的 参数 ， 类 似 的 还 有 : 

. -$: 安全 配置 相关 参数 ， 如 云 连 接 参 数 、Jenkins 连 接 参 数 及 数据 库 连接 参数 等 ， 默 认为 /etc/nodepool/secure.conf。 

. -1: log 配 置 文件 ， 如 果 不 配 置 ， 默 认 值 输出 INFO 级 别 及 INOF 以 上 级 别 的 信息 ， 格 式 为 “时 间 级 别 模块 名 日 志 信 息 ” 

| --debug: 是 否 打 印 调试 信息 ， 默 认为 False。 

2.VM 相 关 操 作 命令 

(1) list 

列 出 当前 Nodepool 创 建 的 所 有 VM 和 状态 ， 以 及 其 对 应 在 云 环境 和 Jenkins 中 的 部 分 信息 ， 该 命令 用 法 如 代码 清单 6-8 所 示 。 


代码 清单 6-8 list 示例 


nodepoolQnodepool:~$ nodepool list 
十 


十 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 一 十 
| ID | Provider | AZ | Label | Target | Manager | 
十 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 一 十 
| 199923 | zte-podll-RegionOne | None | ubuntu-trusty | jenkinsl | None | 
| 199924 | zte-podl13-RegionOne | None | ubuntu-trusty | jenkinsl | None | 
| 199925 | zte-podll-RegionOne | None | ubuntu-trusty | jenkinsl | None | 
| 199926 | zte-podl13-RegionOne | None | ubuntu-trusty | jenkinsl | None | 
4-------- 十 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 一 十 
十 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 十 
Hostname | NodeName 
| 


jenkinsl-ubuntu-trusty-zte-podll-RegionOne-199923 | jenkinsl-ubuntu-trusty-zte-—podll-RegionOne-199923 
RegionOne-199924 | jenkinsi-ubuntu-trusty-zte--pod1l3-RegionOne-1 99924 
RegionOne-199925 | jenkinsi-ubuntu-trusty-zte--pod1ll-RegionOne-1 99925 
RegionOne-199926 | jenkinsi-ubuntu-trusty-zte--pod13-RegionOne-1 99926 


jenkins1-ubuntu-trusty-zte-podl] 
jenkins1-ubuntu-trusty-zte-podl] 
jenkins1-ubuntu-trusty-zte-podl] 


十 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 + 


1bbadl6db-e41b-448f-a8cd-6f9483f2aa0d 172.11 
23728c3d-b5f7-44e6-95c0-74483b43b5b4 172.1] L 
b069e5f0-5917-4f4e-85c5-4805c3158229 172.11 s145 ready | 00:04:40:50 None | 
16ea773a-c970-4fe6-ac9b-d61f3e983680 172.11 .143 ready | 00:04:41:35 | None | 
十 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 一 + 


.137 | used | 00:01:48:48 | None | 
.157 | used | 00:01:48:45 | None | 


: ID: VM 在 Nodepool 中 的 唯一 标识 ， 由 Nodepool 自 动产 生 。 

: Provider: VM 所 处 的 云 环 境 名 称 ， 命 名 方式 为 : <providetr>-<region>，provider 和 region 来 自 于 配置 文件 中 providers 下 的 name 和 region-name。 
| AZ: VM 所 处 的 Availability Zone， 取 值 来自 于 配置 文件 中 providers 下 的 availability-zones。 

: Hostname: VM 在 Jenkins 中 的 名 称 ， 取 值 来 自 于 配置 文件 中 tatgets 下 的 hostname。 

.Setvef ID: 该 VM 在 云 环境 中 的 唯一 标识 ， 该 值 由 云 环境 自动 产生 。 

: Label: VM 可 以 运行 job 的 标签 名 ， 取 值 来 自 于 配置 文件 中 labels 下 的 name。 

: Traget: VM 注册 到 了 哪个 Jenkins， 取 值 来 自 于 配置 文件 中 targets 下 的 name。 

: NodeName: VM 注册 到 Jenkins 中 的 名 称 ， 取 值 来 自 于 配置 文件 中 targets 下 的 hostname。 

IP: 云 环境 分 配给 VM 的 JP， 显 示 浮 动 IP， 如 果 没 有 浮动 JP 了 则 显示 Fixed IP. 


State: 描述 了 当前 VM 在 Nodepool 中 的 状态 ， 其 中 used 表 明 该 VM 已 经 被 Jenkins 使 用 完毕 ， 即 将 被 删除 ，ready 表 明 可 以 运行 ob， 其 他 的 状态 还 有 : delete (VM 需要 删除 或 正在 被 删除 ) ~ hod (VM 不 会 
被 自动 删除 ) 、building (VM 正在 启动 过 程 中 ) 和 test (VM 已 经 启动 成 功 ,， 但 仍 处 在 测试 状态 ， 测 试 成 功 后 会 被 设置 为 treadey) ; 


: Age: 显示 了 当前 VM 从 创建 到 当前 所 经 历 的 时 间 。 
(2) hold 
手动 让 节点 处 于 保持 状态 ， 而 不 会 被 自动 删除 ， 该 命令 在 调试 Job 时 比较 有 用 ， 该 命令 用 法 如 代码 清单 6-9 所 示 。 


代码 清单 6-9 hold 


nodepool@nodepool:~$ nodepool hold -h 
usage: nodepool hold [-h] [--reason REASON] id 


positional arguments: 
id node id 


optional arguments: 
-h, --help show this help message and exit 
--reason REASON Optional reason this node is held 


参数 说 明 如 下 : 
: id: 指 VM 在 Nodepool 中 的 唯一 标识 ， 即 nodepool list 命 令 显 示 结 果 中 ID 一 列 的 值 。 
reason: 用 于 说 明 hold 的 原因 。 

Qiu 

处 于 hold 状 态 的 VM 只 能 手动 删除 ; hold 状 态 的 VM 也 会 占用 云 提供 的 VM 数 ， 为 了 便于 维护 ， 尽 量 提供 REASON 用 以 说 明 该 VM 为 什么 需要 hold。 
(3) delete 

删除 VM ， 即 手动 强制 删除 VM ， 该 命令 用 法 如 代码 清单 6-10 所 示 。 


代码 清单 6-10 delete 


nodepool8nodepool:-$ nodepool delete -h 
usage: nodepool delete [-h] [--now] id 


positional arguments: 
id node id 


optional arguments: 
-h, --help show this help message and exit 
-——-now delete the node in the foreground 


参数 说 明 如 下 : 

: id: 指 VM 在 Nodepool 中 的 唯一 标识 ， 即 nodepool list 命 令 显 示 结 果 中 ID 一 列 的 值 。 

. now: 表明 是 否 立 即 删除 ， 如 果 不 指定 该 参数 ，Nodepool 只 设 定 VM 状 态 为 delete， 并 在 周期 性 检测 任务 中 删除 该 VM。 
Qus 


不 建议 在 Jenkins 上 删除 Nodepool 注 册 的 VM (Slave) , B] A Jenkins M) AVM} 45-38 4e Nodepool, NodepoolfeJenkins I8] 4, 7t 75 FE] 3b Ud], Hr LSU IE 8525 XX fENodepoolP S F "3&3:^ WVM, AIÈ 
的 VM 依然 会 占用 Nodepool 提 供 的 VM 数 ， 极 端 情 况 是 Nodepool 中 已 经 存在 大 量 处 于 ready 状 态 的 VM， 但 Jenkins 中 其 实 无 YM 可 用 。 而 从 Nodepool 中 删除 YM 时 ， 不 仅 会 删除 云 中 的 VM， 也 会 从 Jenkins 中 将 其 注 
销 。 所 以 ， 删 除 VM 应 该 由 Nodepool 自 动 发 起 ， 或 通过 delete 命 令 手 动 发 起 。 


3. 镜 像 相关 操作 命令 
(1) image-list 
列 出 镜像 及 其 信息 ， 包 括 制作 信息 、 上 传 信息 和 在 云 中 的 使 用 情况 。 该 命令 用 法 如 代码 清单 6-11 所 示 。 


代码 清单 6-11 image-list 示 例 


nodepool8nodepool:-$ nodepool image-list 


Build ID Upload ID Provider mage 

0000000035 0000000001 zte-podl1-RegionOne ubuntu-trusty 

0000000035 0000000001 zte-pod13-RegionOne ubuntu-trusty 

0000000045 0000000002 zte-podl1-RegionOne ubuntu-trusty-large 

0000000045 0000000002 zte-pod13-RegionOne ubuntu-trusty-large 

Provider Image Name | Provider Image ID 
cemplate-ubuntu-trusty-1525425224 4£158720-303e-4906-8c8f-0a8a47b655028 
template-ubuntu-trusty-1524061372 cc0077e3-da20b-45e8-9£f57-bb2789a2b4ad 
cemplate-ubuntu-trusty-large-1524052032 087e0e3b-0da8-4ccb-bb08-6ac2d536eceb 
cemplate-ubuntu-trusty-large-1524052040 898ef164-cd56-4a03-a8973-924b0fb4f594 
State Age 

ready | 04:17:02:39 

ready 20:11:53:51 

ready | 20:14:29:25 

ready | 20:14:29:28 


: Build ID: 镜像 制作 的 唯一 标识 ， 从 1 开始 顺序 编号 ; 每 制作 一 次 镜像 ， 无 论 成 功 与 否 ， 该 值 加 1。 


- Upload ID: 茶 个 镜像 上 传 到 指定 云 中 的 索引 号 ， 从 1 开始 顺序 编号 ， 每 上 传 一 次 ， 无 论 结果 是 否 成 功 ， 都 加 1。 


: Provider: VM 所 处 的 云 环 境 名 称 ， 命 名 方式 为 : «provider»-«region» , providerderegion& Á F EG Æ 3C 4 FP providers F 82 nameZferegion-name; 


. Image: 镜像 名 称 ， 取 值 来 自 于 配置 文件 中 diskiamges 下 的 name。 


: Provider Image Name: 镜像 在 云 环境 中 的 名 称 ， 取 值 来 自 于 配置 文件 中 ptovidets 下 的 template-hostname。 


: Provider Image ID: 镜像 在 云 环境 中 的 ID， 该 值 由 云 环境 自动 产生 。 


.State: 描述 了 当前 镜像 在 Nodepool-builder 中 的 上 传 状 态 ， 其 中 teady 表 明 该 镜像 已 经 成 功 上 传 到 一 个 云 环 境 ， 其 他 的 状态 还 有 : 


failed (镜像 上 传 失败 ) 。 


- Age: 


(2) dib-ima 


ge-list 


显示 了 镜像 从 上 传 到 云 环境 开始 到 当前 所 经 历 的 时 间 。 


列 出 制作 的 镜像 及 其 信息 ， 但 不 包含 在 云 中 的 使 用 情况 ， 该 命令 用 法 如 代码 清单 6-12 所 示 。 


代码 清单 6-12 ”dib-image-list 示 例 


nodepool8nodepool:^$ nodepool dib-image-list 


Formats State 
qcow2 ready 
qcow2 building 
qcow2 ready 
qcow2 building 


ID: 镜像 文件 的 唯一 标识 ， 命 名 方式 为 : 


ty-0000000035 
ty-0000000036 
ty-large-0000000045 
ty-large-0000000046 


176:07:38:39 
00:00:07:13 
196:09:32:18 
00:00:10:44 


: Builder: 制作 镜像 的 服务 器 名 称 。 


nodepool.oz 
nodepool.oz 
nodepool.oz 
nodepool.oz 


«Image?-« Build ID», ，Image 和 Build ID 说 明 参 见 6.3.3 一 节 中 的 说 明 。 


: Formats: 镜像 格式 ， 取 值 来 自 于 配置 文件 中 providers 下 的 image-type 和 diskiamges 下 的 formats。 


uploading (镜像 正在 上 传 ) deleting. (镜像 正在 从 云 环境 中 删除 ) 和 


.State: 描述 了 当前 镜像 在 Nodepool-builder 中 的 制作 状态 ， 其 中 ready 表 明 该 镜像 已 经 制作 成 功 ，building 表 明正 在 制作 ， 其 他 的 状态 还 有 : deleting. (镜像 文件 正在 删除 ) 和 failed (镜像 制作 失败 ) o 


£A BET 


dib-image-list 中 反映 的 是 镜像 制作 的 情况 ， 包 括 正在 制作 的 镜像 ，dib-image-list 中 的 镜像 只 有 状态 为 ready 后 才能 在 image-list 中 查看 到 。 


显示 了 镜像 从 制作 开始 到 当前 所 经 历 的 时 间 。 


需要 注意 的 是 ，dib-image-list 中 的 一 个 镜像 记录 可 


image-list 中 对 应 多 条 记录 。 此 外 ，dib-image-list 中 的 每 条 记录 ， 都 会 在 本 地 磁盘 上 有 对 应 的 文件 存在 ， 制 作成 功 的 镜像 如 代码 清单 6-13 所 示 。 


代码 清单 6-13 ”制作 成 功 的 镜像 


nodepool@nodepool:/opt/nodepool dib$ 11 -h 


total 2.0G 
drwxrwxrwx 3 
-rw-r--r-- 1 
-rw-rw-rw- 1 
-rw-rw-rw- 1 
drwxrwxrwx 3 
-rw-r--r-- 1 
-rw-rw-rw- 1 
-rw-rw-rw- 1 


存放 镜像 的 路 径 可 以 在 配置 文件 中 指定 ， 示 例 中 为 /optynodepool dib， 正 在 制作 的 镜像 路 径 也 可 以 配置 ， 如 /opt/dib_ tmp. 


odepool 
odepool 
odepool 
odepool 
odepool 
odepool 
odepool 
odepool 


E. 3E: 1E Aa C EJ SED 9) 03 


(3) image-build 


手动 触 上 制作 新 的 镜像 ， 旧 的 镜像 不 


代码 清单 6-14 


A A AS a 


odepool 
odepoo] 
odepool 
odepoo] 
odepool 
odepoo] 
odepool 
odepoo] 


image-build 


E 
SLR 


nodepool@nodepool:~$ nodepool image-build -h 
usage: nodepool image-build [-h] image 


usty-0000000035.d/ 


rusty-0000000035.qcow2 


tCy-0000000035.qcow2 .md5 


Sty-0000000035.qcow2.sha256 


rusty-large-0000000045.d/ 


-trusty-large-0000000045.qcow2 


sty-large-0000000045.qcow2.md5 


4.0K Apr 8 11:20 ubuntu-tr 
1012M Apr 8 11:22 ubuntu-t 
89 Apr 8 11:22 ubuntu-trus 
121 Apr 8 11:22 ubuntu-tru 
4.0K Apr 28 11:43 ubuntu-t 
1012M Apr 28 11:46 ubuntu 
89 Apr 28 11:46 ubuntu-tru 
121 Apr 28 11:46 ubuntu-tr 


usty-large-0000000045.qcow2.sha256 


响 ， 该 命令 用 法 如 代码 清单 6-14 所 示 。 


能 会 在 


positional arguments: 
image image name 


optional arguments: 
-h, --help show this help message and exit 


其 中 image 是 待 制作 的 镜像 名 称 ， 取 值 来 自 于 配置 文件 中 diskiamges 下 的 name。 
(4) image-delete 
手动 删除 云 环境 中 的 镜像 ， 该 操作 会 触发 新 的 镜像 上 传 。 该 命令 用 法 如 代码 清单 6-15 所 示 。 


代码 清单 6-15  image-delete 


nodepool@nodepool: ~$ nodepool image-delete -h 
usage: nodepool image-delete [-h] --provider PROVIDER --image IMAGE 
--upload-id UPLOAD ID --build-id BUILD ID 


optional arguments: 
-h, --help show this help message and exit 
--provider PROVIDER provider name 
--image IMAGE image name 
--upload-id UPLOAD ID 
image upload id 
--build-id BUILD ID image build id 


参数 provider、image、upload-id 和 build-id 的 更 多 内 容 请 参见 6.3.3 节 中 的 说 明 。 
(5) dib-image-delete 
手动 删除 制作 的 镜像 ， 该 操作 会 触发 新 的 镜像 制作 ， 该 命令 用 法 如 代码 清单 6-16 所 示 。 


代码 清单 6-16 dib-image-delete 


nodepoolQnodepool:~$ nodepool dib-image-delete -h 
usage: nodepool dib-image-delete [-h] id 


positional arguments: 
id dib image id 


optional arguments: 
-h, --help show this help message and exit 


参数 id 的 更 多 内 容 请 参见 6.3.3 节 中 的 说 明 。 
(6) alien-list 


此 命令 列 出 云 环 境 中 Nodepool 可 以 查询 到 但 又 不 在 本 Nodepool 当 前 管理 列表 中 的 外 部 VM。 原理 是 : Nodepool 首 先 通 过 配置 的 去 用 户 查询 所 有 对 接 云 上 的 VM， 如 果 VM 在 Nodepoo 履 k 据 库 中 不 存 
在 ， 则 说 明 是 外 部 VM。 这 些 外 部 VM 可 能 是 因为 异常 或 配置 错误 导致 云 环境 中 的 VM 和 Nodepool 维 护 的 VM 不 一 致 而 留 下 的 ， 此 时 只 能 手动 从 云 中 删除 。 该 命令 用 法 如 代码 清单 6-17 所 示 。 


代码 清单 6-17 ”alien-list 示 例 


a ~$ nodepool alien-list 


基于 以 上 检测 的 原理 ， 如 果 一 个 系统 中 存在 多 个 Nodepool， 都 对 接 同一 个 云 环 境 ， 建 议 为 每 个 Nodepool 配 置 独立 的 租户 ， 这 样 彼此 的 VM 相互 不 可 见 。 
A 
Quse 


alien-list 查 询 出 来 的 VM 与 Nodepool 泄 漏 的 VM 不 同 ， 泄 漏 的 VM 可 以 通过 元 数据 确定 是 本 Nodepool 创 建 并 出 现 了 异常 ， 所 以 可 以 通过 自动 清理 流程 删除 ， 而 alien-list 查 询 出 来 的 VM 可 能 不 是 本 Nodepool 创 建 
的 ， 不 能 证 明 是 否 异常 ， 所 以 不 能 贸然 删除 。 


(7) alien-image-list 


此 命令 可 以 列 出 云 中 Nodepool 可 以 查询 到 但 又 不 在 本 Nodepool 当 前 管理 列表 中 的 外 部 镜像 。 原 理 是 : Nodepool 首 先 通 过 配置 的 去 用 户 查询 所 有 对 接 云 上 的 镜像 ， 如 果 镜 像 在 Zookeeper 中 不 存在 ， 
则 说明 是 外 部 镜像 。 这 些 外 部 镜像 可 能 是 因为 异常 或 配置 错误 导致 云 环境 中 的 镜像 和 Nodepool 维 护 的 镜像 不 一 致 而 留 下 的 ， 此 时 只 能 手动 从 云 中 删除 。 该 命令 用 法 如 代码 清单 6-18 所 示 。 


代码 清单 6-18 alien-image-list 示 例 


ed ~$ nodepool alien-image-list 


Provider Name 

zte-pod13-RegionOne ci-book-template-ubuntu-trusty-1515582892 
zte-podl3-RegionOne ci-book-template-ubuntu-trusty-large-1515578873 
zte-podl1-RegionOne ci-book-template-ubuntu-trusty-1515582892 
zte-podl1-RegionOne ci-book-template-ubuntu-trusty-large-1515578873 


8b81e5a5-616e-4e29-827b-e99c3cfff334 
9947972a-ffb7-44p9-882b-d6a7ff00f677 
94812d828-£491-4805b-890a-2d35b5088636c8 
a4de864fc-f71f-42f2-a473-ec7ea2c' ]fabf 


以 上 输出 中 ， 说 明 还 有 其 他 的 Nodepool 对 接 到 云 zte-pod11-RegionOne 和 zte-pod13-RegionOne， 因 为 当前 Nodepool 镜 像 名 称 在 配置 中 都 是 以 template-ubuntu-* 命 名 的 ， 不 是 ci-book-*， 所 以 
本 Nodepool 将 其 列 为 外 部 的 镜像 并 加 以 显示 。 


Qui 


dib-alien-list 查 询 出 来 的 镜像 与 Nodepool-buildet 泄 漏 的 镜像 不 同 ， 泄 漏 的 镜像 可 以 确定 是 本 Nodepool-buildet 创 建 并 出 现 了 异常 ， 所 以 可 以 通过 自动 清理 流程 删除 ， 而 dib-alien-list 查 询 出 来 的 镜像 可 能 不 是 
本 Nodepool-builder 创 建 的 ， 不 能 证 明 是 否 真 正 出 现 了 异常 ， 所 以 不 能 贸然 删除 。 


4.Job 相 关 操 作 命 令 


有 时 Job 会 随机 失败 ， 而 正常 情况 下 ， 无 论 失 败 还 是 成 功 ， 用 于 Slave 的 VM 都 会 在 Job 运 行 完毕 后 自动 删除 ， 此 时 如 果 想 登录 到 VM 上 进行 故障 定位 是 不 可 能 的 ， 所 以 需要 一 种 手段 让 那些 运行 指定 Job 
失败 的 VM 保持 住 ， 而 不 会 被 自动 和 删除。 下面 这 些 命令 就 是 为 这 个 目的 而 设计 的 ， 可 以 先 通 过 job-create 指 定 需要 调试 的 Job， 并 指明 保持 多 少 个 失败 节点 ， 以 便 定位 问题 ， 一 旦 问题 处 理 完毕 ， 则 使 用 job- 
delete 删 除 刚才 创建 的 Job，job-list 则 用 于 查看 当前 Job 的 信息 ，。 


(1) job-create 
创建 测试 Job， 该 命令 用 法 如 代码 清单 6-19 所 示 。 


代码 清单 6-19 job-create 


nodepool8nodepool:-$ nodepool job-create -h 
usage: nodepool job-create [-h] [--hold-on-failure HOLD ON FAILURE] name 


positional arguments: 
name job name 


optional arguments: 
-h, --help show this help message and exit 
--hold-on-failure HOLD ON FAILURE 
number of nodes to hold when this job fails 


参数 说 明 如 下 : 
: Name: Job 的 名 称 ， 所 取 值 必须 是 和 Nodepool 对 接 的 Jenkins 上 的 某 个 Job 名 。 
< hold-on-failure: 当 Job 出 现 失 败 后 ， 有 多 少 个 VM 需要 处 于 hold 状 态 。 


如 果 通 过 job-create 创 建 了 Job， 那 么 在 该 Job 运 行 失 败 后 ，Nodepool 会 自动 将 Job 所 处 的 前 hold-on-failure 个 VM 置 于 hold 状 态 ， 而 不 会 被 自动 删除 。 因 为 hold-on-failure 次 失败 都 需要 从 Jenkins 触 
发 ， 所 以 一 般 hold-on-failure 取 值 不 要 太 大 。 


该 命令 的 使 用 例子 参见 代码 清单 6-20。 


代码 清单 6-20 job-create 示 例 


nodepoolQnodepool:~$ nodepool job-create zaas-real-deploy --hold-on-failure 5 


ID Name Hold on Failure 


示例 表明 为 zaas-real-deploy 这 个 Job 保 持 5 个 失败 的 VM。 
(2) job-list 
列 出 当前 测试 Job 及 其 对 应 的 处 于 hold 状 态 的 VM 数 ， 如 代码 清单 6-21 所 示 。 


代码 清单 6-21 job-list 示 例 


nodepoolQnodepool:~$ nodepool job-list 


ID Name Hold on Failure 


- ID: Job 的 唯一 标识 ， 由 系统 自动 产生 。 
. Name: Job 的 名 称 。 
: Hold on Failure: 当 Job 出 现 失败 时 ， 当 前 有 多 少 个 VM 需 要 处 于 hold 状 态 。 
(3) job-delete 
删除 测试 Job， 该 命令 不 会 删除 因为 指定 Job 运 行 失 败 而 设置 为 hold 状 态 的 VM ， 只 删除 数据 库 的 Job 记 录 ， 该 命令 用 法 如 代码 清单 6-22 所 示 。 


代码 清单 6-22 job-delete 


nodepool8nodepool:-$ nodepool job-delete -h 
usage: nodepool job-delete [-h] id 


positional arguments: 
id job id 


optional arguments: 
-h, --help show this help message and exit 


参数 jd 的 更 多 内 容 请 参见 6.3.3 节 中 的 说 明 。 

P 

Qu 

因为 job-delete 不 会 删除 已 处 于 hold 状 态 的 VM， 所 以 如 果 某 个 VM 被 自动 设 为 hold 状 态 ， 只 能 手动 删除 。 


[1] https:/ /docs.openstack.oteVinfra/nodepool/opetation.html。 


6.4 配置 Nodepool 


Nodepool 的 配置 主要 涉及 四 个 文件 clouds.yaml、secure.yaml、/etc/nodepool/nodepool.yaml 和 /etc/nodepool/secure.conf， 按 照 Nodepool 对 外 的 连接 关系 分 为 云 配 置 、Jenkins 相 关 配 置 、 镜 
像 相关 配置 以 及 其 他 配置 (如 数据 库 配置 、Zookeeper 配 置 、Gearman 配 置 、 周 期 性 任务 配置 等 ) H11, 


[1] https:/ /docs.openstack.org/infra/nodepool/conf iguration.html o 


64.1 云 相关 配置 

当前 Nodepool 中 用 到 的 Slave 都 来 自 于 云 环境 中 的 VM ， 所 以 正确 配置 云 环境 是 Nodepool 中 的 重要 内 容 ， 该 部 分 的 配置 主要 位 于 clouds.yaml 和 /etc/nodepooynodepoolyaml 中 。 总 体 来 说 ， 云 相关 
配置 包含 两 个 方面 的 内 容 ， 一 个 是 云 连接 参数 (clouds) 配置 ， 另 一 个 是 云 资 源 相关 参数 (providers) 配置 ， 前 者 描述 了 Nodepool 如 何 连 接 到 云 环 境 ， 后 者 定义 了 Nodepool 如 何 使 用 云 环境 。 

1. 云 连接 参数 (clouds) 


在 原理 中 介绍 过 ，Nodepool 可 以 连接 多 个 云 环境 ， 而 云 连 接 配置 本 身 就 比较 复杂 ， 在 较 早 的 Nodepoo|l 版 本 中 ， 云 连接 参数 和 云 资源 相关 参数 是 放 在 一 个 文件 中 的 ， 后 来 为 了 云 管理 的 方便 ， 将 云 环境 
连接 相关 的 大 部 分 参数 (如 云 认证 信息 、 网 络 信息 、 域 信息 以 及 云 环境 提供 服务 的 版 本 信息 等 ) 独立 出 来 ， 并 使 用 os _ client_config 组 件 进行 管理 ， 将 云 连接 作为 一 个 连接 池 ， 云 资源 相关 参数 配置 中 只 需 通 
过 简单 的 引用 即 可 ， 这 样 屏蔽 了 云 连 接 相关 的 细节 ， 增 加 了 Nodepool 管 理 云 的 灵活 性 。 云 连接 参数 放 在 文件 clouds.yaml 和 secure.yam|l 中 ， 使 用 时 会 以 下 面 顺 序 搜索 这 些 文件 : 


(1) 当前 目录 

(2) ~/.config/openstack 

(3) /etc/openstack 

主要 参数 说 明 如 下 : 

client: 可 选 参数 ， 云 环境 是 否 支 持 ipv6， 还 是 强制 为 ipv4: 

: force_ipv4: 可 选 参 数 ， 取 值 为 tue， 表 明 强 制 支持 ipv4， 如 果 为 false， 表 明 不 强制 使 用 ipv4， 默 认为 false。 

: prefer ipv6: 可 选 参 数 ， 取 值 为 tue， 表 明 优 先 使 用 ipv6， 如 果 为 fse， 则 系统 自动 将 force_ipv4 置 为 tue， 默 认为 false。 


proftle: 可 选 参 数 ， 前 面 说 过 ，Nodepool 通 过 使 用 os_client_config 屏 蔽 了 到 云 环境 的 连接 细节 ， 这 样 不 同 的 厂商 只 要 按照 os_clieht_config 的 要 求 提 供 不 同 的 云 连 接 文件 ， 厂 家 特有 的 云 就 可 以 被 Nodepool 
使 用 ，profile 参 数 就 是 用 来 对 接 私 有 云 的 ， 它 是 一 个 网 络 管理 策略 名 称 ， 对 应 一 个 同名 的 json 文 件 ， 其 中 配置 对 接 私 有 云 用 到 的 一 系列 参数 ， 包 括 认 证 信息 和 tegion 等 。 如 下 面 代 码 清单 6-23 所 示 的 是 intetnap 策 
略 对 应 的 文件 内 容 。 


代码 清单 6-23 ”internap 云 连接 参数 


internap", 
"profile": { 

"auth"; 1 
"auth url": "https://identity.api.cloud.iweb.com" 


"regions": [ 
"ams01" i 
"da01", 
"nyj Or" j 
"sin01", 
"Sj col" 
], 
"identity api version": "3", 
"floating ip source": "None" 


: floating ip source: 可 选 参数 ， 浮 动 IP 使 用 的 管理 工具 ， 默 认为 neutron。 

- api timeout: 可 选 参数 ， 通 过 API 访 问 云 环 境 超时 时 间 ， 如 果 不 设置 ， 则 不 做 超时 检查 。 

“service_type: 可 选 参数 ， 服 务 类 型 ， 如 compute， 默 认为 空 。 

-setvice name: 可 选 参数 ， 服 务 名 称 ， 如 compute， 默 认为 空 。 

: image format: 可 选 参数 ， 创 建 VM 时 使 用 的 镜像 格式 。 

. auth: 可 选 参 数 ， 认 证 相关 配置 ， 描 述 连接 Openstack 服 务 时 的 认证 参数 ， 默 认 使 用 用 户 名 和 密码 方式 认证 。 
: auth url: 可 选 参 数 ， 认 证 服务 器 的 u 地 址 ， 如 : 


auth url: http://172.20.0.11:5000/v2.0 


- username: 可 选 参数 ， 访 问 云 环 境 使 用 的 用 户 名 。 

: password: 可 选 参 数 ， 访 问 云 环境 使 用 的 用 户 密码 。 

' project name: 可 选 参数 ， 访 问 云 环境 使 用 的 租户 名 。 

. 如 果 云 环境 使 用 安全 连接 ， 也 可 以 通过 SSL 方 式 进行 认证 。 


key: 可 选 参数 ， 访 问 云 环境 所 使 用 SSL 的 认证 密 钥 路 径 ， 如 : 


key: /home/myhome/client-cert.key 


cert: 可 选 参数 ， 访 问 云 环境 所 使 用 SSL 的 认证 文件 路 径 ， 如 : 


cert: /home/myhome/client-cert.crt 
“ cacert: 可 选 参数 ， 访 问 云 环境 所 使 用 CA 的 文件 路 径 ， 如 : 
cacert: /home/myhome/ca.crt 


verify: 可 选 参数 ，SSL 认 证 是 否 启用 ， 黑 认为 true。 

.tegions: 可 选 参 数 ， 云 环境 中 的 regions 配 置 列 表 ， 会 被 providers 中 的 各 rtegion-name 引用， 每 个 region 和 包含 如 下 选项 : 

- name: 必 选 参数 ， 云 环境 的 tegion 名 称 。 

- values: 可 选 参数 ，tegion 下 的 相关 配置 ， 当 前 只 有 网 络 配置 。 

.netwotks: 必 选 参数 ，tegion 下 网 络 相关 配置 列表 ， 列 表 中 每 个 配置 包含 如 下 信息 : 

Q name: 必 选 参数 ， 网 络 名 称 ， 取 值 必须 是 对 应 云 环境 下 已 存在 的 网 络 名 。 

Q routes externally: 可 选 参 数 ， 网 络 是 否 是 外 部 网 络 ， 即 分 配 浮动 IP 的 网 络 ， 默 认为 false。 

@nat_destination: 可 选 参数 ， 网 络 是 否 启用 NAT 功 能 ， 默 认 false。 

Q default interface: 可 选 参数 ， 网 络 是 否 是 VM 默认 使 用 的 网 络 ， 多 网 络 下 有 效 ， 默 认为 伺 se， 如 果 只 有 一 个 网 络 ， 则 该 网 络 强制 为 默认 网 络 。 
Ou 

同一 个 tegion 下 ， 只 能 有 一 个 网 络 配置 nat_destination 的 值 为 tue， 也 只 能 有 一 个 网 络 配 置 default_interface 的 值 为 tue， 否 则 校 验 会 出 错 。 


Qu 


如 果 region 下 的 networks 配 置 为 列表 ， 那 么 该 region 下 的 VM 创建 后 会 存在 多 个 网 口 ， 每 个 网 口 分 别 连 接 不 同 的 网 络 。 
: identity api version: 可 选 参数 ， 认 证 服务 即 keystone 的 版 本 ， 默 认为 “2.0”。 

- compute, api version: 可 选 参数 ， 计 算 服 务 即 nova 的 版 本 ， 上 默认 为 “2”。 

: image api use tasks: 可 选 参数 ， 镜 像 服 务 即 glance 的 版 本 ， 默 认为 “2”。 

: network api version: 可 选 参数 ， 网 络 服务 的 即 neutton 的 版 本 ， 黑 认为 “2 o 

配置 示例 如 代码 清单 6-24 所 示 : 


代码 清单 6-24 ” 云 连 接 参数 配置 


client: 
force ipv4: true 
prefer ipv6: false 
clouds: 
cloudl: 
floating ip source: 'neutron' 
auth: 
username: 'ciuser' 
password: 'ciuser' 
project name: 'ciuser' 
auth url: 'http://172.20.0.11:5000/v2.0' 
regions: 
- name: RegionOne 
values: 
networks: 
- name: admin floating net 
routes externally: true 
- name: net-ci 
nat destination: true 
default interface: true 


cloug2: 
auth: http://www.hzcourse.com/resource/readBook?path-/openresources/teach ebook/uncompressed/17933/OEBPS/Text/..http://www.hzcourse.com/resource/readBook?path-/openresource 
key: /home/myhome/client-cert.key 
cert: /home/myhome/client-cert.crt 
cacert: /home/myhome/ca.crt 
verify: true 


上 面 的 例子 配置 了 两 个 云 环境 ， 分 别 为 coud1 和 cloud2， 两 个 云 环境 都 使 用 IPV4， 使 用 neutron 管 理 浮 动 |P， 此 外 cloud2 启 用 了 ssL 认 证 ，cloud1 则 没有 启用 。cloud1 定 义 了 一 个 region Bp 
RegionOne; 该 region 下 定义 了 两 个 网 络 ， 即 admin floating_net 和 net-ci， 其 中 admin floating_net 是 分 配 浮动 |P 的 外 网 ， 而 net-ci 是 内 部 默认 网 络 ， 在 net-ci 网 络 启 用 了 nat 功 能 。 


为 了 提高 云 连 接 的 安全 性 ， 可 以 将 云 连接 配置 clouds.yaml 中 的 敏感 信息 (如 用 户 、 密 码 等 ) 放 在 secure.yaml 中 ， 并 对 文件 secure.yam| 的 权限 加 以 特别 限制 ， 如 只 允许 管理 员 查 看 和 修改 ， 使 用 时 两 
个 配置 文件 中 的 配置 项 会 进行 合并 ， 如 果 配 置 项 都 存在 则 会 使 用 secure.yaml 中 的 配置 ，secure.yaml 中 的 配置 示例 如 代码 清单 6-25 所 示 。 


代码 清单 6-25” 云 连接 配置 参数 -secure 


clouds: 
cloudl: 
auth: 
username: 'ciuser' 
password: 'ciuser' 
project name: 'ciuser' 


本 示例 中 将 代码 清单 6-24 中 云 cloud1 的 认证 信息 (包括 用 户 名 、 用 户 密码 和 租户 等 ) 放 在 安全 文件 secure.yaml 中 。 
Qu 
云 连接 参数 配置 文件 clouds.yaml 和 secure.yaml 的 后 级 也 可 以 是 yml， 如 果 配 置 是 json 格 式 ， 后 级 还 可 以 是 json。 


2. 云 资源 相关 参数 (providers) 


云 资 源 相关 参数 描述 了 Nodepool 如 何 使 用 云 ， 换 句 话 说 就 是 云 环境 可 以 为 Nodepoo| 提 供 哪 些 资源 ， 这 些 参数 主要 定义 了 云 环境 中 可 供 Nodepool 使 用 的 AZ 列表 、 最 大 VM 数 、Nodepool 创 建 VM 可 
以 使 用 的 镜像 以 及 VM 启 动 相关 参数 等 ， 该 配置 位 于 /etc/nodepooynodepool.yaml 文 件 中 。 


主要 配置 参数 如 下 : 

.cloud: 可 选 参数 ， 连 接 云 环境 名 称 ， 该 值 需 要 在 clouds.yaml 中 存在 。 

 region-name: 可 选 参数 ， 提 供给 Nodepool 的 源 环境 中 的 tegion 名 称 ， 如 果 不 配置 ， 则 默认 使 用 第 一 个 region。 
Qu 
cloud 和 region-name 唯 一 确定 一 个 云 环境 ， 通 过 cloud 和 region-name 可 以 得 到 云 连接 的 相关 配置 。 


auth-utl: 可 选 参 数 ， 认 证 服务 器 的 ul 地 址 ， 如 : 
auth-url: http://172.20.0.11:5000/v2.0 


- username: 可 选 参 数 ， 访 问 云 环 境 使 用 的 用 户 名 。 
: password: 可 选 参 数 ， 访 问 云 环境 使 用 的 用 户 密码 。 
“ project-name: 可 选 参数 ， 访 问 云 环境 使 用 的 租户 名 。 
Qu 
project-name 4E A JE j& A.P "| Eproject-id. tenant-id S,tenant-name o 
Og 
ptovidet 使 用 云 连 接 有 两 种 方式 : 通过 cloud 引 用 cloud.yaml 云 连接 参数 或 者 直接 在 nodepool.yaml 中 定义 连接 参数 (包括 auth_utl、username、password 和 project_name 等 ) ， 推 荐 使 用 cloud 方 式 。 
- name: 必 选 参数 ， 云 环境 的 名 称 。 
- max-servers: 必 选 参数 ， 云 环境 能 为 Nodepool 提 供 的 最 大 VM 数目 。 
` image-type: 可 选 参数 ， 创 建 VM 时 使 用 的 镜像 格式 ， 黑 认为 qcow2。 
Qu 
image-type 会 初始 化 为 cloud.yaml 配 置 中 的 image_format， 所 以 provider 中 一 般 不 用 配置 。 


- availability-zones: 可 选 参 数 ，Nodepool 可 以 使 用 的 availability zone (AZ) 列表 ; 如 果 不 设置 该 创建 VM 时 完全 依赖 于 nova 自 己 调度 结果 ; 如 果 设 置 了 多 个 AZ，Nodepool 创 建 VM 时 会 随机 选择 一 
个 ， 所 以 如 果 需 要 更 精确 地 控制 Nodepool 使 用 的 AZ， 需 要 在 云 环境 中 定义 更 详细 的 AZ， 然 后 再 提供 给 Nodepool 使 用 。 


boot-timeout: 可 选 参数 ， VM 启动 超时 时 间 ， 即 从 VM 处 于 active 状 态 到 SSH 连 接 成 功 的 最 长 等 待 时 间 ， 单 位 为 秒 ; 如 果 启动 超时 ，Nodepool 认 为 创建 VM 失败 ， 从 而 删除 该 VM; 该 参数 默认 为 60 秒 。 
:launch-timeout: 可 选 参数 ，VM 上 电 超 时 时 间 ， 即 VM 创建 开始 到 VM 处 于 active 状 态 的 最 长 等 待 时 间 ， 单 位 为 秒 ， 如 果 上 电 超 时 ，Nodepool 认 为 创建 VM 失败 ， 从 而 删除 该 YM; 该 参数 默认 为 3600 秒 。 
. keypair: 可 选 参数 ， 创 建 VM 使 用 的 公 钥 ， 默 认 不 使 用 。 

networks: 可 选 参数 ， 创 建 VM 时 使 用 网 络 名 称 列 表 ， 列 表 中 每 个 配置 包含 如 下 信息 。 

name: 必 选 参数 ， 网 络 名 称 ， 取 值 必 须 是 对 应 云 环境 下 已 存在 的 网 络 名 。 

. ipv6-preferred: 可 选 参数 ， 取 值 为 tue，Nodepool 向 Jenkins 注 册 VM 时 会 尝试 使 用 IPV6 网 络 ， 如 果 失 败 或 者 配置 为 false 会 使 用 IPV4 网 络 ; 该 参数 默认 为 false。 


.tate: 可 选 参 数 ，Nodepool 创 建 VM 的 最 短 间 隔 时 间 ， 单 位 为 秒 ;) 如 果 有 大 量 的 VM 需 要 同时 创建 ， 会 给 云 环 境 带 来 性 能 上 的 压力 ， 所 以 可 以 通过 设置 该 参数 减少 Nodepool 对 云 环境 的 冲击 ; 该 参数 默认 


: clean-floating-ips: 可 选 参数 ， 如 果 设 置 为 true，Nodepool 会 周期 性 地 尝试 清理 没有 使 用 的 浮动 ITP， 这 样 可 以 避免 浮动 JP 泄漏 ， 默 认为 false。 
` api-timeout: 可 选 参数 ， 通 过 API 访 问 云 环 境 超时 时 间 ， 如 果 不 设置 则 不 做 超时 检查 。 

.setvice-type: 可 选 参 数 ， 服 务 类 型 ， 如 compute， 默 认为 空 。 

“service-name: 可 选 参数 ， 服 务 名 称 ， 如 compute， 黑 认为 空 。 

Qu 

api-timeout、 service-type 和 service-name 推 荐 在 clouds.yaml 中 配置 。 


: template-hostname: 可 选 参 数 ， 镜 像 在 该 云 环 境 下 的 名 称 模板 ， 如 {image.name}-{timestamp}-nodepool-template， 创 建 VM 时 image.name 和 timestamp 会 被 替换 为 具体 的 值 ， 还 有 一 个 变量 是 {fprovider} ; 该 参 


数 默 认为 template-{image.name}-{timestamp}。 
images: 必 选 参数 ， 定 义 了 Nodepool 在 云 环境 下 创建 VM 时 可 以 使 用 的 镜像 列表 ， 列 表 中 的 每 项 都 必须 存在 于 镜像 配置 的 “diskimages” 中 ， 其 中 : 
: name: 必 选 参数 ， 镜 像 的 名 称 。 
: min-ram: 必 选 参数 ， 表 明 创 建 VM 时 需要 的 最 小 内 存 大 小 。 
. name-ftlter: 可 选 参数 ， 取 值 为 字符 囊 ， 用 于 描述 选择 亿 vor 时 的 附加 信息 ， 如 设置 performance 表 明 需 要 选择 元 数据 包含 performance 的 flavor， 如 果 有 多 个 flavor 满 足 条 件 ， 则 随机 选择 一 


Qu 


通过 同时 设置 min-ram 和 name-ftltet 两 个 参数 可 以 精确 选择 创建 VM 时 使 用 的 flavor。 

: pause: 可 选 参 数 ， 表 明 是 否 使 用 该 镜像 ，true 表 示 使 用 ，false 表 示 不 使 用 ; 默认 为 false。 

username: 可 选 参 数 ，Nodepool 创 建 VM 后 ， 通 过 SSH 使 用 该 参数 指定 的 用 户 名 连接 VM; 默认 为 jenkins。 

: private-key: 可 选 参 数 ，Nodepool 通 过 SSH 连 接 VM 所 使 用 用 户 秘 钥 的 绝对 路 径 ， 默 认为 /var/lib/jenkins/.ssh/id_rsa。 
: conftg-drive: 可 选 参 数 ，Nodepool 创 建 VM 时 是 否 使 用 config-drive， 上 默认 为 false。 

- meta; 可 选 参 数 ，Nodepool 创 建 VM 时 ， 注 入 的 元 数据 信息 ， 为 一 系列 key-value 对 ，key 和 value 长 度 都 不 超过 255。 
配置 示例 如 代码 清单 6-26 所 示 。 


代码 清单 6-26 ” 云 资源 相关 参数 配置 


providers: 
- name: providerl 
cloud: example 
region-name: 'regionl' 
max-servers: 96 
rate: 1.0 
availability-zones: 
= azl 
boot-timeout: 120 
launch-timeout: 900 
template-hostname: 'template-{image.name}-{timestamp}' 
ipv6-preferred: False 
networks: 
- name: 'some-network-name' 
images: 
- name: trusty 
min-ram: 8192 
name-filter: 'something to match' 
image-type: qcow2 
username: jenkins 
user-home: '/home/jenkins' 
private-key: /var/lib/jenkins/.ssh/id rsa 


meta: 
key: value 
key2: value 
- name: precise 
min-ram: 8192 
username: jenkins 
user-home: '/home/jenkins' 
private-key: /var/lib/jenkins/.ssh/id rsa 
- name: devstack-trusty 
min-ram: 30720 
username: jenkins 
private-key: /home/nodepool/.ssh/id rsa 
- name: provider2 
username: 'username' 
password: 'password' 
auth-url: 'http://auth.provider2.example.com/' 
project-name: 'project' 
service-type: 'compute' 
service-name: 'compute' 
region-name: 'regionl' 
max-servers: 96 
rate: 1.0 
template-hostname: 'í(image.name)-(timestamp]-nodepool-template' 
images: 
- name: precise 
min-ram: 8192 
username: jenkins 
user-home: '/home/jenkins' 
private-key: /var/lib/jenkins/.ssh/id rsa 


meta: 
key: value 
key2: value 


示例 中 为 Nodepool 定 义 了 两 个 云 环境 ， 分 别 是 provider1 和 provider2， 其 中 provider1 使 用 了 cloud+region-name 方 式 连接 云 ， 最 大 提供 96 个 VM ， 使 用 的 AZ 为 az1， 网 络 名 为 Some-network- 
name (cloud 中 定义 的 网 络 也 会 使 用 ) ， 同 时 为 Nodepool 提 供 了 3 种 镜像 ， 即 trusty (需要 元 数据 注入 ) 、precise 和 devstack-trusty， 用 三 种 镜像 创建 VM 时 需要 的 内 存 分 别 是 8GB、8GB 和 30GB; VM 
建成 功 后 ，Nodepool 登 录 VM 的 用 户 名 都 是 jenkins， 密 钥 位 于 /home/nodepool/.ssh/id_rsa。 


provider2 直 接 使 用 了 传统 的 方式 ， 云 连接 信息 直接 显 式 定义 在 例子 中 ， 并 指明 了 服务 类 型 为 compute， 可 以 为 Nodepoo| 提 供 的 最 大 VM 数 为 96。provider2 中 只 使 用 了 1 种 镜像 即 precise (需要 元 数 
据 注 入 ) ， 使 用 该 镜像 创建 VM 需要 的 内 存 为 8GB， 创 建成 功 后 连接 VM 的 用 户 名 为 jenkins， 密 钥 位 于 /var/lib/jenkins/.ssh/id_rsa 中 。 


6.4.2 ”Jenkins 相 关 配 置 

Nodepool 管 理 的 VM 最 终 都 会 作为 Jenkins 的 Slave， 所 以 申请 多 少 VM、 如 何 将 这 些 VM 注册 到 Jenkins 中 是 Nodepool 配 置 的 又 一 个 重要 的 内 容 ， 该 部 分 配置 位 于 /etc/nodepool/secure.conf 
和 /etc/nodepool/nodepool.yaml 中 ， 按 功能 分 为 Jenkins 连 接 参数 配置 、target 配 置 和 label 配 置 等 。 

1.Jenkins 连 接 参 数 

为 了 安全 ，Jenkins 的 连接 相关 参数 配置 如 用 户 名 、apikey、url 以 及 credentials 等 放 在 /etc/nodepool/secure.conf 中 ， 配 置 要 求 如 代码 清单 6-27 所 示 。 


代码 清单 6-27 ”Jenkins 连 接 参数 


[jenkins "(target name}"] 
url-[url) i 
user-([user] 
apikey-(apikey] 
credentials-ícredentialsj 


"target name: 必 选 参数 ， 连 接 的 Jenkins 名 称 ， 唯 一 标识 一 个 Jenkins 连 接 ， 如 jenkins1。 
. ul: 必 选 参数 ，Jenkins 对 外 提供 的 RESTful API 地 址 ， 如 : http://jenkins1.example.com:8080。 
-useri 必 选 参数 ，Nodepool 通 过 RESTful API 访 问 Jenkins 的 用 户 名 ， 如 Jenkins。 


.ap 站 ey: 必 选 参数 ，Nodepool 通 过 RESTful APIZA (user? 37 [9] Jenkins 63 AIEN 8 o 
pikey p 


Qu 


apikey 可 以 通过 访问 Jenkins webuiffs], 343 7j Jf P ££ configure API Token， 如 图 6-9 所 示 。 


«EQ search (D jenkins !logout 


Jenkins  » jenkins 


* People Full Name jenkins 
a Status Description 


EÈ Builds 


$2 Configure 
& My Views 


A Credentials API Token 
User ID 


3 
API Token 


jenkins 


fdiicfaebab8659d7í8a3e7cb0649a6d 


Change API Token 


图 6-9 Jenkins API Key 
: credentials: 必 选 参数 ，Jenkins 以 SSH 方 式 登 录 Slave 执 行 Job 任 务 时 使 用 的 认证 信息 ，Jenkins 的 credentials 可 以 是 用 户 名 和 密码 ， 也 可 以 是 密 钥 等 信息 ， 具 体 可 以 参见 第 4 章 中 的 credentials 相 关 描 述 。 
Jenkins 连 接 参 数 配置 示例 如 代码 清单 6-28 所 示 。 


代码 清单 6-28 Jenkins 连 接 参数 示例 


[jenkins "jenkins1"] 

url-http://jenkins:8080 

user-jenkins 
apikey-fdllcfaebab8659g7f8a3e7cb0649a6d 
credentials-0e779e44-eb45-4266-864c-d729ab16c15a 


该 示例 只 为 Nodepool 定 义 了 一 个 Jenkins 服 务 器 ， 名 字 为 jenkins1， 对 外 ur| 是 http:/WVjenkins:8080， 访 问 该 服务 器 的 用 户 名 是 jenkins， 认 证 信息 apikey 是 
fd11cfaebab8659d7f8a3e7cb0649a6d，Jenkins 要 访问 Nodepool 创 建 的 VM ， 需 要 使 用 0e779e44-eb45-4266-864c-d729ab16c15a 指 定 的 信息 进行 连接 。 


2.targets 

targets 定 义 了 Nodepoo| 需 要 连接 的 Jenkins， 并 规定 了 创建 VM 时 的 hostname 等 。target 配 置 位 于 文件 /etc/nodepool/nodepool.yaml 中 。 
主要 参数 如 下 : 

: name: 必 选 参数 ，Jenkins 名 称 ， 表 明 VM 需 要 注册 到 哪个 Jenkins 中 ， 取 值 于 上 文 Secure.conf 的 target_name。 


hosthame: 可 选 参 数 ， 创 建 VM 时 的 hostname 模 板 ， 如 {label.name}-{provider.name}-{node_id}， 变 量 在 创建 VM 时 会 被 具体 值 蔡 代 ， 还 有 一 个 可 用 的 变量 是 {ftimestamp}; 该 参数 默认 值 为 {label.name}- 


{provider.name}-{node_id}。 
subnode-hostname: 可 选 和 参数， 创建 子 VM 时 的 hostname 模 板 ， 含 义 同 上 ， 该 参数 默认 值 为 {flabel.name}-{provider.name}-{node_id}-{subnode_id}。 


fate: 可 选 参数 ，Nodepool 注 册 VM 到 Jenkins 的 最 短 间隔 时 间 ， 单 位 为 秒 ; 如 果 有 大 量 的 VM 需 要 同时 注册 到 Jenkins， 会 给 Jenkins 带 来 性 能 上 的 压力 ， 可 以 通过 设置 该 参数 减少 Nodepool 对 Jenkins 的 冲 
击 ; 该 参数 默认 为 1.0。 


. jenkins: 可 选 参数 ， 定 义 和 Jenkins 相 关 的 附加 信息 ， 目 前 只 有 运行 测试 Job 的 名 称 。 


test-job: 可 选 参数 ， 测 试 Job 的 名 称 ， 该 名 称 必 须 来 自 于 Jenkins 中 的 有 效 Job 名 称 ; 如 果 配 置 了 该 参数 ， 在 VM 创建 成 功 后 ， 会 首先 处 于 test 状 态 ， 然 后 Nodepool 会 通知 Jenkins 触 发 该 Job 运 行 ， 运 行 结束 后 
Jenkins 会 将 运行 的 结果 以 ZeroMQ 消 息 通 知 Nodepool， 如 果 运 行 成 功 ，Nodepool 会 将 VM 置 为 teady 状 态 ， 如 果 和 失败， 该 VM 将 会 被 删除 ， 如 果 一 直 没 有 运行 结果 通知 给 Nodepool， 该 VM 将 会 在 周期 性 清理 过 程 
中 被 清除 。 


- assign-via-gearman: 可 选 参 数 ， 是 否 立 即 通知 geatman 分 配 Job 给 新 建 的 VM，ttue 为 立即 通知 ，false 为 不 通知 ; 默认 为 false。 
Qu 
hostname 既 是 VM 在 Jenkins 中 的 显示 名 称 ， 也 是 在 云 环境 中 的 显示 名 称 ，subnode-hostname 代 表 的 VM 只 会 出 现在 云 环境 中 ， 不 会 被 注册 到 Jenkins 中 。 
配置 示例 如 代码 清单 6-29 所 示 。 


代码 清单 6-29 Jenkins 连 接 相 关 参 数 配置 


targets: 

- name: jenkins1 
hostname: '(label.name]-(provider.name]-(node id]' 
subnode-hostname: 'ílabel.name)-íprovider.name]-(node id}-{subnode id}' 

- name: jenkins2 E i 
hostname: '(label.name]-(provider.namej]-(node id]' 
jenkins: m 

test-job: zaas-check 


代码 清单 6-29 说 明了 Nodepool 创 建 的 VM 需要 注册 到 两 个 Jenkins 中 ， 分 别 是 jenkins1 和 jenkins2， 但 同一 时 刻 一 个 VM 只 能 存在 于 一 个 Jenkins 中 ; 其 中 jenkins1 中 还 定义 了 子 节点 的 hostname 模 板 ， 
注册 到 jenkins2 VM 需要 通过 zaas-check 测 试 才能 运行 其 他 Job。 


3.labels 


labels 摘 述 了 Nodepool 需 要 为 Jenkins 创 建 多 少 类 型 (一 个 label 表 明 一 种 类 型 ) 的 VM ， 每 种 类 型 的 VM 需 要 多 少 个 ， 以 及 从 哪些 云 中 、 使 用 什么 镜像 创建 VM ， 是 否 需要 子 节点 等 。Nodepool 会 按照 
这 些 定义 要 求 创建 VM ， 并 注册 到 Jenkins 中 ， 这 些 VM 在 注册 到 Jenkins 时 会 打上 对 应 的 标签 类 型 ， 作 为 Jenkins 运 行 Job 时 选择 的 依据 。labe 配 置 位 于 文件 /etcnodepooMnodepool.yaml 中 。 


主要 参数 如 下 : 

name: 必 选 参数 ， 定 义 了 标签 名 称 ， 作 为 标识 VM 的 类 型 。 

providers: 必 选 参数 ， 云 名 称 列表 ， 定 义 了 指定 类 型 的 VM 可 以 在 哪些 云 中 创建 ， 这 些 云 名称 必 须 存在 于 providers 定 义 的 云 列表 中 。 
. image: 必 选 参数 ， 镜 像 名 称 ， 定 义 了 创建 指定 类 型 的 VM 使 用 的 镜像 ， 该 镜像 名 称 必须 存在 于 providers 对 应 云 的 镜像 列表 中 。 

: min-ready: 可 选 参数 ， 该 参数 定义 了 Nodepool 需 要 为 Jenkins 创 建 指定 类 型 Slave 的 最 小 数目 ， 默 认为 2。 


'subnodes: 可 选 参数 ， 该 参数 定义 了 是 否 需要 为 注册 到 Jenkins 中 的 VM 创 建 子 节点 ， 每 个 子 节点 也 对 应 一 个 同 种 类 型 的 VM; 如 果 定 义 具体 值 ，Nodepool 则 会 为 每 个 注册 到 Jenkins 的 VM 创 建 对 应 数目 的 


子 VM， 子 VM 不 注册 到 Jenkins 中 ，VM 和 子 VM 之 间 可 以 相互 通信 ; 该 参数 默认 为 0。 
.tfeady-sctipt: 可 选 参 数 ， 该 参数 定义 了 在 VM 注册 到 Jenkins 前 需要 通过 的 测试 脚本 ， 这 些 测试 脚本 是 由 Nodepool 发 起 执行 的 。 
A 
Qu 


此 处 的 ready-script 和 target 中 定义 的 test-job 有 所 不 同 ， 前 者 是 由 Nodepool 在 VM 中 执行 的 本 地 脚本 ， 脚 本 一 般 比 较 固 定 ， 需要 注入 到 VM 镜像 中 ， 后 者 运行 的 是 Jenkins 上 的 Job 所 定义 的 脚本 ， 较 为 灵活 。 
两 者 的 共同 点 都 是 由 Nodepool 主 动 发 起 的 测试 ， 只 不 过 一 个 是 直接 执行 ， 一 个 是 间接 执行 。 


配置 示例 如 代码 清单 6-30 所 示 。 
代码 清单 6-30 ”标签 参数 配置 


labels: 

- name: my-precise 
image: precise 
min-ready: 2 
providers: 

- name: providerl 
- name: provider2 

- name: multi-precise 
image: precise 
subnodes: 2 
min-ready: 2 
ready-script: setup multinode.sh 
providers: 

- name: providerl 


代码 清单 6-30 中 定义 了 两 种 类 型 的 节点 ， 分 别 是 my-precise 和 multi-precise， 前 者 需要 Nodepool 启 动 2 个 VM 注 册 给 Jenkins 作 为 Slave; 后 者 需要 6 个 VM ， 并 分 成 两 组 ， 每 组 一 个 主 VM ， 两 个 子 
VM ， 且 主 VM 会 注册 到 Jenkins 中 。my-precise 由 两 个 provider 提 供 VM ，multi-precise 只 有 一 个 provider 提 供 VM。 另 外 ，multi-precise 还 定义 了 VM 必 须 通过 的 测试 脚本 setup_multinode.sh， 这 个 脚本 
是 事先 注入 到 VM 中 的 。 


6.4.3 ”镜像 配置 (diskimages) 

镜像 配置 主要 是 定义 制作 镜像 时 用 到 的 一 些 参 数 信 息 ， 重 点 是 编译 镜像 需要 的 Element， 通 过 使 用 不 同 的 Element， 就 可 以 制作 满足 不 同 需求 的 VM 镜 像 。 此 外 ， 还 可 以 配置 镜像 的 基础 版 本 、 镜 像 的 格 
式 、 镜 像 的 老化 时 间 ， 以 及 制作 镜像 时 注入 的 一 些 环境 变量 等 。 镜 像 配 置 位 于 文件 /etc/nodepool/nodepool.yaml 中 。 

镜像 配置 主要 参数 如 下 : 

- name: 必 选 参数 ， 镜 像 名 称 ， 被 云 配置 provider 引 用 。 

. pause: 可 选 参数 ， 该 参数 说 明 当 前 配置 是 否 生效 ，true 为 生效 ， 钙 se 为 不 生效 ， 默 认为 tue。 

. rebuild-age: 可 选 参数 ， 该 参数 定义 镜像 的 老化 时 间 ， 超 过 该 时 间 镜 像 会 重新 制作 ， 单 位 为 秒 ， 默 认为 86400 秒 。 

.formats: 可 选 参数 ， 该 参数 定义 了 镜像 格式 列表 ， 如 raw、qcow2 或 tarf 等 ， 具 体 取 值 参 见 6.5 节 中 的 说 明 ; 该 参数 默认 为 空 。 

. release: 可 选 参数 ， 定 义 了 基础 镜像 的 版 本 ， 这 个 配置 需要 结合 Element 基 础 OS 配置 ， 如 取 值 precise 时 一 定 要 选择 ubuntu 的 基础 Element; 默认 为 室 。 


: elements: 可 选 参 数 ， 定 义 了 镜像 制作 过 程 中 用 到 的 一 系列 脚本 或 文件 ， 可 以 是 标准 的 Element 也 可 以 自 定义 的 Blement， 如 果 和 包含 自 定义 的 Element， 需 要 指定 环境 变量 DIB_ELEMENT_PATH 或 在 配 


置 文件 中 配置 elements-dit 参 数 ; 该 参数 默认 为 空 。 
env-vatrs: 可 选 参数 ， 定 义 了 制作 镜像 时 用 到 的 一 些 环境 变量 ， 可 以 是 标准 的 环境 变量 ， 也 可 以 是 自 定义 变量 ( 自 定义 Element 中 使 用 ) 。 
Qiu 
镜像 配置 中 可 以 没有 镜像 类 型 ， 类 型 会 取 自 于 具体 云 环境 下 对 应 镜像 的 image-type， 如 果 同 一 镜像 在 不 同 的 云 配置 下 的 格式 不 同 ，Nodepool 会 为 每 个 云 配 置 生成 一 个 镜像 文件 。 
Qiu 
虽然 elements 是 可 选 参数 ， 但 是 实际 应 用 时 都 会 配置 为 一 定 的 值 ， 以 便 将 一 些 常 用 的 包 或 配置 做 到 镜像 中 ， 否 则 使 用 Nodepool 功 能 上 就 会 大 打折 扣 。 
镜像 配置 示例 如 代码 清单 6-31 所 示 。 


代码 清单 6-31 镜像 参数 配置 


diskimages: 

- name: precise 
pause: false 
rebuild-age: 86400 
elements: 

- ubuntu-minimal 
- um 
- simple-init 
- openstack-repos 
- nodepool-base 


cache-devstack 
cache-bindep 
growroot 


- infra-package-needs 
release: precise 


TMPDIR: /opt/dib tmp 
DIB CHECKSUM: '1' 
DIB IMAGE CACHE: /opt/dib cache 
DIB APT LOCAL CACHE: '0' 
DIB DISABLE APT CLEANUP: '1' 
FS TYPE: ext3 

- name: xenial 

pause: true 

rebuild-age: 86400 
formats: 

— raw 

= tar 
elements: 

- ubuntu-minimal 

= um 

- simple-init 

- openstack-repos 

- nodepool-base 

- cache-devstack 

- cache-bindep 

- growroot 

- infra-package-needs 
release: precis 


TMPDIR: /opt/dib tmp 
DIB CHECKSUM: '1' 
DIB IMAGE CACHE: /opt/dib cache 


DIB APT LOCAL CACHE: '0' 
DIB DISABLE APT CLEANUP: '1' 
FS TYPE: ext3 


代码 清单 6-31 中 定义 了 两 个 ubuntu 镜像 ， 分 别 是 precise 和 Xenial， 前 者 基于 Ubuntu precise 版 本 制作 镜像 ， 后 者 基于 Ubuntu xenial 版 本 制作 镜像 ， 两 者 定义 了 相同 的 Element， 说 明 需 要 预 装 相同 的 
软件 包 。xenial 还 指明 了 需要 两 种 格式 的 镜像 ， 分 别 是 raw 和 tar; 由 于 precise 中 pause 为 false， 所 以 实际 是 不 会 制作 precise 镜 像 的 。 


关于 镜像 制作 尤其 是 配置 什么 样 的 Element， 不 是 一 件 容 易 的 事 ， 需 要 对 操作 系统 和 镜像 制作 原理 有 一 定 的 了 解 ，6.5 节 会 讲解 Nodepool 中 镜像 制作 的 原理 ， 可 以 作为 镜像 配置 的 入 门 参考 。 


6.4.4 其 他 配置 

除了 以 上 几 个 配置 之 外 ，Nodepool 还 有 其 他 一 些 配置 ， 包 括 镜像 文件 路 径 的 配置 、Zookeeper 服 务 的 配置 、Gearman 服 务 的 配置 、 周 期 性 任务 的 配置 等 ， 这 些 配置 都 位 
于 /etc/nodepoolnodepoolyaml 中 。 

1. 镜 像 目 录 


Nodepool 使 用 diskimage-builder 和 glance 来 制作 镜像 和 上 传 镜像 ， 镜 像 存 储 在 本 地 ， 需 要 指明 存储 路 径 ， 在 制作 镜像 的 过 程 中 ， 常 常 需 要 引用 自 定义 的 Element， 也 需要 为 这 些 Element 指 定 搜索 路 
径 ， 这 些 路 径 配 置 位 于 /etc/nodepool/nodepool.yam 中 。 


- elements-dir: 可 选 参 数 ， 自 定义 Element 的 存放 绝对 路 径 ， 默 认为 空 。 
images-dif: 必 选 参数 ， 用 来 定义 镜像 存放 的 路 径 。 


配置 示例 如 下 : 


elements-dir: /etc/nodepool/elements 
images-dir: /opt/nodepool dib 


2. 数 据 库 配置 


主要 是 数据 库 的 连接 信息 ， 位 于 /etc/nodepool/secure.conf 文 件 中 ， 配 置 如 下 : 


[database] 
dburi-í(dburi] 


其 中 {dburi) 为 数据 库 的 配置 ， 包 括 配 置 引 擎 和 连接 信息 ， 例 如 


dburiemysql-tpymysql://nodepool: root1238common/nodepool 


3. 周 期 性 任务 


Nodepool 有 多 个 周期 性 的 任务 ， 其 中 cleanup 用 于 周期 性 清理 过 期 的 镜像 和 没有 删除 成 功 的 VM ，check 用 于 周期 性 检查 VM 是 否 可 用 ， 具 体 通过 SSH 连 接 判 断 VM 是 否 可 用 可 达 ， 如 果 不 可 达 则 认为 该 
VM 不 可 用 。 配 置 示例 如 代码 清单 6-32 所 示 ，。 


代码 清单 6-32 周期 性 任务 参数 配置 


cron: 
Cleanup: '*/1 * * * xi 
check: "4/15 $ * x 


其 中 时 间 的 格式 符合 UNIX cron 风 格 [， 但 具体 取 值 有 所 差别 ， 由 * 分 割 的 前 五 个 字段 含义 分 别 是 : 
- 分 取 值 : 0 一 59 

时 取 值 : 0 一 23 

| 天 取 值 : 1 一 31 

: 月 取 值 : 1 一 12 

- 星期 取 值 : 0—63Xmon. tue. wed. thu. fri. sat. sun. (和 UNIX cton 不 同 ) 


与 标准 UNIX cron 风 格 的 另 一 个 差别 是 ， 如 果 配 置 第 六 个 参数 ， 则 会 被 解释 为 秒 ， 取 值 学 围 是 0 ~ 59。 


4.ZeroMQ 


定义 了 Jenkins 提 供 的 ZeroM Q 服 务 端点 (地 址 + 端口 ) 列表 ，Nodepool 通 过 该 连接 获取 Jenkins 关 于 节点 的 实时 消息 ， 对 于 使 用 完毕 的 节点 ，Nodepool 会 启动 删除 节点 流程 ， 配 置 示例 如 代码 清单 6- 
33 所 示 。 


代码 清单 6-33” ZeroMQ ”连接 参数 配置 


zmq-publishers: 
- tcp://jenkinsl.example.com:8888 
- tcp://jenkins2.example.com:8888 


5.Gearman-servers 


Gearman 服 务 器 列表 ， 端 口 默认 4730，Nodepool 连 接 到 Gearman 服 务 器 上 以 便 实 时 获取 需要 新 建 节点 的 相关 信息 ， 其 中 等 待 运行 的 Job 信 息 来 自 于 Zuul， 正 在 运行 的 Job 信 息 来 自 于 Jenkins， 配 置 示 
例如 代码 清单 6-34 所 示 。 


代码 清单 6-34 Gearman 人 参数 配置 


gearman-servers: 
- host: zuul.example.com 
port: 4730 


6.zookeeper-servers 
Zookeeper 服 务 列表 ， 用 于 Nodepool 内 部 各 组 件 之 间 交 换 镜像 相关 信息 ， 配 置 示例 如 代码 清单 6-35 所 示 。 


代码 清单 6-35 Zookeeper% E 


zookeeper-servers: 
- host: zkl.example.com 
port: 2181 
chroot: /nodepool 


其 中 port 是 可 选 参数 ， 默 认 2181; chroot 也 是 可 选 参数 ， 用 于 定义 Zookeeper 中 镜像 根 节点 的 名 称 ， 默 认 /nodepool， 对 于 多 Nodepool 共 享 Zookeeper 服 务 时 比较 有 意义 ， 可 以 为 每 个 Nodepoo| 配 
置 一 个 根 节点 ， 这 样 各 Nodepool 间 镜像 信息 彼此 独立 。 


[1] https:/ /docs.acquia.com/atticle/cron-time-string-format. 


6.5 ”镜像 管理 系统 


自动 制作 工具 目前 有 很 多 ， 主 要 有 diskimage-builder、Oz、VMBuilder、VeeWee、Packer 以 及 ImageFactory 等 ，Nodepool 中 Nodepool-builder 使 用 的 制作 工具 为 diskimage-builder， 简 称 
DIB。 


6.5.1 ”DIB 介绍 

DIB 是 OpenStack 中 TripleO 下 的 子 项 目 ， 功 能 较为 完善 ， 支 持 主流 的 Linux 操 作 系 统 的 镜像 制作 ， 包 括 fedora、centos、ubuntu 及 debian 等 ,支持 的 格式 也 比较 多 ， 如 qcow2、tar、tgz、vhd、 
docker、aci、raw 及 sdquashfs 等 。 

1.DIB 安 装 


首先 安装 依赖 包 qemu-utils 和 kpartx， 如 : 


# apt-get install -y qemu-utils 
# apt-get install -y kpartx 


然后 安装 DIB: 


# pip install diskimage-builder 


也 可 以 通过 源码 方式 安装 DIB: 


# git clone https://git.openstack.org/openstack/diskimage-builder 
# cd diskimage-builder 
# pip install -e . 


2.DIB 使 用 


DIB 使 用 比较 简单 ， 只 需要 通过 简单 的 配置 即 可 使 用 ， 如 


4 disk-image-create -o centos7 -t qcow2 centos7 vm 


上 面 的 命令 运行 完毕 即 可 生成 qcow2 格 式 的 centos7 的 镜像 ， 按 下 面 的 方式 可 以 生成 raw 格 式 Ubuntu14.04 的 镜像 : 


# disk-image-create -o ubuntu -t raw ubuntu vm 


如 果 需 要 生成 Ubuntu16.04 镜 像 ， 只 需要 设置 export DIB RELEASE=xenial 即 可 。 下 面 是 disk-image-create 的 常用 参数 : 


:-a: 指定 i386|amd64|atmhf 架 构 类 型 ， 默 认为 amd64。 

-oO imagename: 指定 输出 的 镜像 名 称 ， 默 认为 镜像 的 名 称 。 

:-t: 取 值 gcow2、tar、vhd、docker、aci 或 taw ， 指 定 输出 的 镜像 文件 格式 ， 默 认为 dcow2。 
(xD 打开 调试 信息 。 

(ul 不 压缩 镜像 ， 镜 像 文件 较 大 ,但 是 执行 快 。 

-ci 表示 开始 工作 之 前 先 清理 环境 。 

< --checksum: 为 创建 的 镜像 文件 产生 MD5 和 SHA256 校 验 和 文件 。 

` --image-size size: 设置 创建 镜像 的 大 小 ， 单 位 为 GB。 


: --image-cache directory: 本 地 缓存 镜像 的 路 径 ， 黑 认为 “~/.cacheV/image-cteate” 。 


: --max-online-resize size: 设置 支持 的 最 大 文件 系统 块 ; 需要 一 个 真实 大 小 的 根 分 区 时 候 ， 这 个 参考 


 -min-tmpfs size: 设置 建立 镜像 时 host 上 需要 的 最 小 GB 的 tmpfs。 

: -mkfs-options: 设置 mkfs 命 令 调用 的 参数 ， 整 个 参数 为 一 个 字符 串 。 
 --no-tmbfs: 不 使 用 tmpfs 加 速 镜像 创建 。 

: -off line: 不 更 新 缓存 资源 。 

- -qemu-img-options: 设置 qemu-img 命 令 调 用 的 参数 。 

. -root-labellabel: 指定 根 文件 系统 的 标签 ， 默 认为 “cloudimg-rootfs”。 

: -ramdisk-element: 指定 用 于 建立 镜像 的 主要 元 素 ， 默认 有 “ramdisk”。 

: --install-type: 指定 默认 安装 类 型 ， 上 默认 为 “source，” 也 可 以 设置 为 “package ”用 于 包 的 安装 。 
: —docker-target: 如 果 输 出 类 型 为 docketr， 则 需 指 定 repo 和 tag， 默 认为 镜像 名 称 。 
(oni 跳 过 默认 的 “base ”元素 选项 ，RAMDISK 特 有 的 选项 。 

-pb package[,package,package]: 列举 在 镜像 中 需要 额外 安装 的 包 。 

: -h|--help: 显示 帮助 信息 。 

: —version: 显示 版 本 信息 。 

Ou 


至 少 需 要 指定 一 个 Element， 如 果 使 用 VHD 输出 格式 ， 还 需要 安装 vhd-util。 


6.5.2 ”DIB 原理 


图 6-10 ”Linux 文件 系统 


在 介绍 DIB 原 理 之 前 ， 我 们 先 看 看 Linux 的 文件 系统 ， 从 工作 空间 上 来 说 ，Linux 文 件 系 统 分 为 bootfs 和 rootfs， 前 者 位 于 内 核 空间 ， 后 者 位 于 用 户 空间 ， 如 图 6-10 所 示 。 


Linux 刚 启动 时 会 加 载 bootfs 文 件 系统 ， 然 后 加 载 rootfs， 我 们 熟悉 的 /dev、/proc、/bin 等 目录 就 位 于 rootfs 中 。 不 同 Linux 发 行 版 的 区 别 主要 是 rootfs， 比 如 Ubuntu 14.04 使 用 upstart 管 理 服 务 ，apt 
管理 软件 包 ， 而 CentOS 7 使 用 systemd 和 yum， 这 些 都 是 用 户 空间 上 的 区 别 ， 内 核 空间 差别 不 大 。 而 对 于 一 个 精简 的 操作 系统 ，rootfs 可 以 很 小 ， 只 需要 包括 最 基本 的 命令 、 工 具 和 程序 库 就 可 以 了 ,一 般 
只 有 几 十 到 几 百 兆 。 不 同 版 本 的 Linux 系 统 都 会 发 布 这 样 的 精简 操作 系统 ， 并 扒 带 bootfs， 我 们 称 其 为 初始 根 文件 系统 ，DIB 就 是 基于 这 些 初 始 根 文 件 系统 增加 需要 的 软件 包 来 制作 镜像 的 。 


DIB 的 原理 如 图 6-11 所 示 。 


Host 


/tmp 
/dib image.xxxxxxxx 
/dib build.xxxxxxxx 
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/hooks 
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图 6-11 DIB 原 理 图 
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镜像 制作 需要 的 初始 根 文件 系统 ， 可 以 从 对 应 操作 系统 的 官网 上 下 载 ， 利 用 losetup、qemu-img 和 kpartx 等 一 系列 工具 ， 在 Host (运行 DIB 的 系统 ) 中 将 初始 根 文件 系统 和 预定 义 安装 配置 脚本 放 到 临 
时 目录 中 ， 通 过 chroot 改 变 系统 的 根 路 径 (mnt) ， 然 后 依次 运行 预定 义 的 安装 配置 脚本 来 定制 需要 的 系统 和 软件 。 这 些 预定 义 脚本 按 运行 阶段 分 8 个 目录 ， 都 位 于 Host 的 临时 目录 hooks 中 ， 运 行 时 根据 
最 终 作 用 环境 ， 这 些 目录 会 映射 到 目标 系统 即 Target 的 /tmp/in_target.d 目 录 下 (下文 会 详细 描述 这 8 个 阶段 ) 。 最 后 将 安装 了 定制 软件 的 目标 系统 转换 成 需要 的 镜像 格式 ， 这 样 一 个 定制 化 的 镜像 就 制作 成 


Df. 


v Eu cleanup.d 
EN 50-root 
Y Bgenvironment.d 
E 75-nodepool-base-env 
v Bmextra-data.d 


a ri 


RU a Me PST RV 
vw Bufinalise.d 
89-journald-persistent 
EN 89-unbound 
EN 99-nodepool-dir 
Y Bminstall.d 
05-record-details 
EN 06-record-builddate 
EN 20-iptables 
EH 50-disable-metadate 
59-sudoers 
EN 89-install-zuul 
91-venv-os-testr 
EH 96-clean-cron 
EN 99-disable-rfc3041 
v Bupost-install.d 
EB 20-iptables 
89-jenkins-scripts 
Y Bupre-install.d 
EN 10-preseed 
a element-deps 
F package-installs.yaml 
iSt README.rst 


-cloudinit 


图 6-12 ” Element 例子 一 一 nodepool-base 


从 以 上 过 程 中 可 以 看 到 ， 使 用 DIB 制 作 镜 像 的 关键 是 一 些 “ 预 定义 的 安装 配置 脚本 ”， 这 些 脚本 决定 了 定制 的 结果 ， 为 了 方便 管理 ，DIB 中 将 这 些 脚 本 称 为 Element， 并 按照 镜像 制作 的 8 个 阶段 规定 了 
Element 中 目录 及 文件 的 组 成 。 一 个 典型 的 Element 如 图 6-12 所 示 。 


Qus 


基于 DIB 的 工作 原理 ， 初 始 文件 系统 也 可 以 基于 Linux 发 行 版 而 不 仅仅 是 精简 系统 ， 还 可 以 基于 一 些 特殊 场景 (比如 操作 系统 内 核 也 是 定制 ， 而 非 来 自 官方 ) 来 制作 镜像 。 
1.DIB 8 个 阶段 
DIB 镜 像 制作 过 程 包括 8 个 阶段 ， 分 别 对 应 8 个 目录 ， 如 表 6-3 所 示 。 


表 6-3 DIB8 个 阶段 
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block-device block-device.d RSS Ju » x 
定型 阶段 
Host 清理 阶段 


由 于 DIB 运 行 在 HOST 上 ， 通 过 chroot 来 决定 Element 是 作用 在 目标 系统 上 ， 还 是 HOST 系统 上 ， 所 以 这 个 运行 环境 对 每 个 阶段 非常 重要 ， 下 面 在 描述 每 个 阶段 时 都 会 特别 加 以 说 明 。 另 外 ， 对 于 每 个 阶 
段 如 果 存 在 多 个 Element 需 要 执行 ， 则 会 按照 文件 名 排序 ， 每 个 阶段 的 脚本 名 都 会 以 两 个 数字 开始 ， 用 以 决定 执行 顺序 。 


(1) root 阶 段 

初始 化 根 文 件 系统 阶段 ， 通 常 是 在 已 经 存在 的 初始 镜像 上 增加 定制 的 文件 内 容 。 
. 运行 环境 : Hosto 

“ 输入: 

- $ARCH=i386 | amd64 | atmhf | arm64 

: STARGET. ROOT- /path/to/tatget/workarea 

. 处 理 : 按照 文件 名 的 字母 顺序 依次 运行 foot.d 目 录 下 的 可 执行 脚本 。 

“ 输出 无 。 


本 阶段 完成 之 后 ，rootfs 需 要 的 /bin、/sbin、/etc、/lib、/usr 等 目录 及 其 中 包含 的 文件 就 产生 了 ，rootfs 中 包含 的 内 容 取决 于 执行 的 县 体 脚 本 。 代 码 清单 6-36 所 示 的 是 ubuntu Element 在 root 阶 段 的 
人 处理 。 


代码 清单 6-36 Element ubuntu 在 root 阶 段 的 处 理 


# **10-cache-ubuntu-tarball** 
DIB CLOUD IMAGES=${DIB CLOUD IMAGES:-http://cloud-images.ubuntu.com) 
DIB RELEASE=${DIB RELEASE:-trus 24 
BASE IMAGE FILE-S$(BASE IMAGE FILE:-$DIB RELEASE-server-cloudimg-$ARCH-root.tar.gz]) 
SHA256SUMS-$ ( SHA256SUMS : -https: //S{DIB CLOUD IMAGES##http?(s)://}/$DIB RELEASE/current/SHA256SUMS} 
CACHED FILE=$DIB IMAGE CACHE/SBASE IMAGE FII 

CACHED FILE LOCK-SDIB LOCKFILES/SBASE IMAG 
CACHED SUMS-$DIB IMAGE CACHE/SHA256SUMS.ubun! 


u.SDIB RELEASE.SARCH 


function get ubuntu tarball() { 
if [ -n "SDIB OFFL NE" -a -f "SCACHED FILE" ] then 
echo "Not checking freshness of cached SCACHED FILE." 


else 


echo "Fetching Base Image" 

STMP HOOKS PATH/bin/cache-url $SHA256SUMS $CACHED SUMS 

S$TMP HOOKS PATH/bin/cache-url \ i 
$DIB CLOUD IMAGES/SDIB RELEASE/current/SBASE IMAGE FILE $CACHED FILE 


pushd $DIB IMAGE CACHE 
if ! grep "SBASE IMAGE FILE" $CACHED SUMS | sha256sum --check - ; then 
i uu -f $SHA256SUMS $CACHED SUMS 
if ! p "SBASE IMAGE FILE" SCACHED SUMS | sha256sum --check - ; then 
Sn HOOKS PATH/bin/cache-url -EN 


$DIB CLOUD IMAGES/SD B RELEASE/current/SBASE . MAGE FILE $CACHED FILE 
grep "SBASE IMAGE FILE" $CACHED SUMS | sha256sum --check - 


fi 


J.T. 
popd 


Ei 
sudo tar -C STARGET ROOT --numeric-owner -xzf $DIB IMAGE CACHE/SBASE IMAGE FILE 


echo "Getting SCACHED FILE LOCK: $(date)" 
# Wait up to 20 minutes for another process to download 
if ! flock -w 1200 9 ; then 

echo "Did not get $CACHED FILE LOCK: $(date)" 


exit 1 v 


fi 
get ubuntu tarball 
) 9» SCACHED FILE LOCK 


由 代码 清单 6-36 可 知 ，ubuntu Element 在 root 阶 段 主 要 是 根据 用 户 设置 的 ubuntu 版 本 (DIB RELEASE) 从 对 应 的 地 址 (DIB CLOUD IMAGES) 下 载 初始 根 文件 系统 ， 缓 存 初 始 根 文件 系统 在 指定 的 
目录 (DIB IMAGE CACHE) T. 


(2) extra-data 阶 段 


准备 数据 阶段 。 从 宿主 机 中 将 需要 的 文件 (如 SSH 密 钥 、http 代 理 设置 等 ) 复制 到 制作 镜像 的 临时 目录 $TMP_HOOKS_PATH 中 。 


. 运行 环 境 : Host o 


: 输入: $TMP HOOKS PATH; 
- 处 理 : 按照 文件 名 的 字母 顺序 依次 运行 extra-data.d 目 录 下 的 可 执行 脚本 。 


"输出: 无 。 


本 阶段 运行 完毕 后 ， 需 要 的 文件 已 经 从 Host 上 复制 到 Target 对 应 的 目录 中 ， 复 制 的 具体 内 容 和 位 置 取决 于 执行 的 脚本 。 代 码 清单 6-37 所 示 的 是 Element dpkg 在 extra-data 阶 段 的 处 理 。 
代码 清单 6-37 Element dpkg 在 extra-data 阶 段 的 处 理 


4 **01-copy-apt-keys** 


DIB ADD APT KEYS-S(DIB ADD APT KEYS:-""] 

if [ -z "S(DIB ADD APT KEYS)" ]; then 
echo "DIB ADD APT KEYS is not set - not importing keys" 
exit 0 


£1 


DIR=$ {TMP MOUNT PATH)/tmp/apt keys 
f [ -e ${DIR} ]; then 

echo "S(DIR) already exists!" 
exit 1 


H- 


fi 
sudo mkdir -p S(DIR) # dib-lint: safe sudo 


# Copy to DIR 
for KEY in $(find ${DIB_ADD APT KEYS) -type f); do 
sudo cp -L S$(KEY) S(DIR) # dib-lint: safe sudo 


done 
由 代码 清单 6-37 可 知 ，dpkg Element 在 extra-data 阶 段 定义 了 一 个 处 理 脚本 ， 位 于 01-copy-apt-keys 文 件 中 ， 主 要 完成 的 就 是 复制 apt-keys 到 Target 系 统 中 。 
(3) pre-install 阶 段 
预 安装 阶段 ， 一 般 用 来 准备 软件 包 安 装 需要 用 到 的 仓库 ， 该 阶段 是 在 Target 中 运行 的 第 一 个 阶段 。 
. 运行 环境 : Target. 
输入: 无 。 
. 处 理 : 按照 文件 名 的 字母 顺序 依次 运行 pre-install.d 目 录 下 的 可 执行 脚本 。 
E 输出: 无 。 


本 阶段 运行 完毕 后 ， 预 安装 阶段 的 准备 工作 就 完成 了 ， 需 要 准备 的 具体 内 容 取 决 于 具体 的 执行 脚本 。 需 要 注意 的 是 ， 虽 然 也 可 以 在 此 阶段 做 一 些 包 的 安装 操作 ， 但 不 建议 这 么 做 ， 包 的 安装 放 在 下 一 个 
阶段 进行 。 代 码 清单 6-38 所 示 的 是 Element ubuntu 在 pre-install 阶 段 的 处 理 。 


代码 清单 6-38 Element ubuntu 在 pre-install 阶 段 的 处 理 


4 **00-remove-apt-xapian-index** 
apt-get --yes remove apt-xapian-index || : 


4 **00-remove-grub** 

if dpkg-query -W grub-pc ; then 
apt-get -y remove grub-pc 

fi 


f dpkg-query -W grub2-common; then 
apt-get -y remove grub2-common 


H- 


d **0l-set-ubuntu-mirror** 
DIB DISTRIBUTION MIRROR-$(DIB DISTRIBUTION MIRROR:-) 


[ -n "SDIB DISTRIBUTION MIRROR" ] || exit 0 


sudo sed -ie "s&http://N(archiveN|securityN) .ubuntu.com/ubuntu&SDIB DISTRIBUTION MIRROR&" \ 
/etc/apt/sources.list 


由 代码 清单 6-38 可 知 ，ubuntu Element 在 pre-install 阶 段 定 义 了 三 个 脚本 ， 分 别 是 00-remove-apt-xapian-index、00-remove-grub 和 01-set-ubuntu-mirror， 前 面 两 个 脚本 是 删除 不 需要 的 软件 ， 
最 后 一 个 是 设置 软件 安装 的 repo 地 址 为 用 户 指定 的 地 址 。 

(4) install 阶 段 

安装 阶段 ， 即 安装 预定 义 的 软件 ， 镜 像 绝 大 多 数 的 包 都 是 在 这 个 阶段 处 理 的 ， 这 个 阶段 的 执行 通常 需要 消耗 最 长 的 时 间 。 

. 运行 环境 : Target. 

E 输入 : 无 。 

- 处 理 : 按照 文件 名 的 字母 顺序 依次 运行 install.d 目 录 下 的 可 执行 脚本 。 

E 输出: 无 。 

本 阶段 运行 完毕 后 ， 为 镜像 定制 的 绝 大 多 数 软 件 包 已 经 安装 完毕 ， 具 体 需 要 安装 哪些 软件 包 取决 于 具体 定义 的 脚本 和 相关 定义 文件 (如 element-deps 等 ) 。Element ubuntu 在 install 阶 段 的 处 理 如 下 


所 示 : 


4 **99-autoremove** 
apt-get -y autoremove 


由 上 可 知 ，ubuntu Element 在 安装 阶段 的 最 后 会 清理 系统 缓存 包 。 


(5) post-install 阶 段 
安装 后 处 理 阶 段 ， 包 成 功 安装 后 ， 在 第 一 次 启动 前 需要 执行 的 任务 都 在 此 阶段 处 理 。 例 如 通过 chkconfig 关 闭 一 些 服务 ， 或 对 安装 的 服务 进行 配置 等 ;也 可 以 清理 一 些 缓存 的 软件 包 ， 以 减 小 镜像 的 大 
小 。 


- 运行 环境 : Target. 


CAN: 无 。 
“处理: 按照 文件 名 的 字母 顺序 依次 运行 post-install.d 目 录 下 的 可 执行 脚本 。 
输出: 无 。 


本 阶段 运行 完毕 后 ， 定 制 镜像 的 文件 系统 已 经 基本 完成 ， 相 关 软件 的 配置 也 已 经 准备 就 绪 ， 具 体 需要 做 哪些 后 处 理 取决 于 具体 定制 的 脚本 。 


毕 
Qu 
需要 注意 的 是 ， 在 此 阶段 完成 后 ，DIB 会 自动 运行 fsttim 工 具 来 真正 清理 “垃圾 文件 ， 释 放 垃 圾 文件 占用 的 磁盘 空间 ， 有 效 减 小 镜像 文件 的 大 小 ， 所 以 如 果 对 最 终 镜 像 文件 大 小 有 特别 的 限制 ， 在 此 阶 
段 需要 将 不 必要 的 文件 删除 ， 以 减少 镜像 大 小 。 


代码 清单 6-39 所 示 的 是 Element ironic-agent 在 post-install 价 段 的 处 理 。 


代码 清单 6-39 Element ironic-agent 在 post-installf 介 段 的 处 理 


4 **80-ironic-agent** 
rm -rf /tmp/ironic-python-agent 


case "SDIB INIT SYSTEM" in 
upstart) 
if [ -f /etc/init/ufw.conf ]; then 
mv /etc/init/ufw.conf /etc/init/ufw.conf.disabled 
fi 
if [ -£f /etc/init/tgt.conf ]; then 
mv /etc/init/tgt.conf /etc/init/tgt.conf.disabled 
fi 
systemd) 
if [[ $(systemctl --no-pager list-unit-files iptables) =~ 'enabled' ]]; then 
systemctl disable iptables.service 
fi 


systemctl enable $(svc-map ironic-python-agent).service 
systemctl enable ironic-agent-create-rescue-user.path 


SYSV) 
update-rc.d iptables disable 


rr 


*) 


echo "Unsupported init system" 
exit 1 


esac 
由 代码 清单 6-39 可 知 ，ironic-agent 安 装 完成 后 ， 除 了 删除 垃圾 文件 ， 还 会 茶 用 防火 墙 。 
(6) block-device 阶 段 

块 设 备 处 理 阶 段 ， 对 磁盘 进行 分 区 、 分 区 文件 系统 、 挂 载 系统 目录 等 操作 都 在 此 阶段 处 理 。 
| 运行 环境 : Hosto 

输入: 

: $SIMAGE, BLOCK, DEVICE- (path! 

- STARGET. ROOT- {path} 

“ 处 理 : 按照 文件 名 的 字母 顺序 依次 运行 block-device.d 目 录 下 的 可 执行 脚本 。 

- 输出 : $IMAGE BLOCK. DEVICE- {path} 。 

本 阶段 运行 完毕 后 ， 镜 像 的 分 区 、 分 区 文件 系统 及 挂 载 系统 目录 等 都 会 确定 。 具 体 需 要 分 几 个 区 、 每 个 区 使 用 什么 文件 系统 、 分 区 挂 载 的 目录 以 及 分 区 是 否 自动 上 电 挂 载 等 取决 于 选择 的 Element 中 分 
区 文件 的 定义 。 代 码 清单 6-40 所 示 的 是 系统 默认 的 MBR 分 区 定义 。 


代码 清单 6-40 ”默认 MBR 分 区 定义 


4 **block-device-default.yaml** 


- local loop: 
name: imageO0 


-partitioning: 
base: imageO0 
label: mbr 
partitions: 

- name: root 
flags: [ boot, primary ] 
size: 100$ 
mkfs: 

mount: 

mount point: / 
fstab: 


options: "defaults" 
fsck-passno: 1 


默认 的 MBR 分 区 只 定义 了 root 一 个 主 分 区 ， 主 分 区 也 是 启动 分 区 ， 占 用 整个 磁盘 空间 ， 并 且 启 动 后 自动 挂 载 到 “/” 目 录 。 除 了 MRB 分 区 方式 之 外 ，DIB 还 支持 GPT 分 区 方式 。 


E. 
名 注解 
要 在 镜像 制作 过 程 中 支持 分 区 操作 ， 除 了 选择 需要 的 分 区 Element (block-device-mbr、block-device-gpt 或 block-device-efi) 外 ， 还 必须 选择 vm 这 个 Element， 否 则 DIB 不 会 对 镜像 进行 
包含 根 文 件 系统 的 镜像 。 
(7) finalise 阶 段 


定型 阶段 ， 对 根 文 件 系统 做 最 后 的 设置 ， 常 党 用 来 设置 SELinux、 安 装 bootloaders 等 。 


“ 运行 环境 : Target。 


CAMAS: 无 。 
CADRE: 按照 文件 名 的 字母 顺序 依次 运行 finalise.d 目 录 下 的 可 执行 脚本 。 
输出: 无 。 
= bb 


这 是 修改 目标 系统 的 最 后 一 个 阶段 ， 所 以 需要 限制 在 此 阶段 的 软件 安装 。 如 果 在 finalise 阶 段 安 装 了 bootloader， 那 么 此 阶段 运行 完成 之 后 ， 一 个 可 启动 的 镜像 就 制作 完毕 。 
如 在 制作 虚 机 启动 的 VM 时 ， 需 要 使 用 vm 这 个 Element， 在 finalise 阶 段 就 会 处 理 SELinux 或 安装 bootloader grub2， 由 于 代码 较 多 ， 有 兴趣 的 读者 可 以 查阅 DIB 中 bootloader 这 个 Element 的 处 理 。 
(8) cleanup 阶 段 

清理 阶段 ， 一 般 用 来 清理 Host 上 一 些 不 必要 的 垃圾 文件 、 包 缓存 文件 或 临时 代码 等 。 

- 运行 环境 : Host. 

E 输入 。 

- $ARCH=i386 |amd64 | armhf |arm64 

. $TARGET_ROOT=/path/to/target/workarea 

` 处 理 : 按照 文件 名 的 字母 顺序 依次 运行 cleanup.d 目 录 下 的 可 执行 脚本 。 

输出 : 无 。 

此 阶段 运行 完毕 后 ， 会 根据 配置 转换 镜像 格式 ， 即 从 raw 格 式 转换 为 gcow2、tar 等 用 户 配 置 的 格式 。 

2. 其 他 目录 和 文件 

除了 上 面 提 到 的 8 个 目录 外 ，DIB 还 提供 了 下 面 的 几 个 目录 或 文件 ， 有 的 是 DIB 直 接 使 用 的 ， 有 的 是 其 他 Element 要 求 的 ， 下 面 讲解 几 个 常用 的 目录 和 文件 。 


environment.d: 环境 设置 目录 ， 放 置 设置 环境 变量 的 脚本 ，DIB 在 上 述 每 个 阶段 的 脚本 执行 前 ， 都 会 运行 该 目录 下 的 脚本 。 代 码 清 单 6-41 所 示 的 是 Element ubuntu 环境 变量 的 定义 。 


代码 清单 6-41 Element ubuntu 环境 变量 的 定义 


# **10-ubuntu-distro-name.bash** 
export DISTRO NAME-ubuntu 
export DIB RELEASE=${DIB RELEASE:-xenial) 


# **99-cloud-init-datasources.bash** 
export DIB CLOUD INIT DATASOURCES-S (D B CLOUD . N T DATASOURCES:-"Ec2"] 


: element-deps: 依赖 文件 ， 纯 文本 格式 ， 指 明 本 Element 依 赖 的 其 他 Element 名 称 ， 每 个 依赖 一 行 。 如 代码 清单 6-42 所 示 是 Element ubuntu 依赖 的 其 他 Elements 定 义 。 


代码 清单 6-42 Element ubuntu 使 用 的 其 他 Elements 


cache-url 
cloud-init-datasources 
dkms 

dpkg 

ubuntu-common 


* package-installs.yaml: 安装 包 定 义 文件 ，yaml 格 式 ， 描 述 了 在 Element 执 行 过 程 中 需要 安装 的 包 。 该 文件 被 package-install Element 使 用 ， 所 以 如 果 存 在 该 文件 ， 需 要 在 element 中 定义 package-install。 定 义 时 


除了 指明 软件 包 名 称 外 ， 还 需要 指定 如 下 信息 : 
. phase: 包 操 作 执 行 的 阶段 ， 默 认 install.d。 
.uninstall: 包 是 安装 还 是 卸载 ， 例 se 表示 安装 ，ttue 表 示 印 载 ， 默 认 false。 
:installtype: 安装 类 型 ， 取 值 source 或 pkg， 默 认 pkg 安 装 方式 。 
dib_python_version: Python 版 本 ，2 或 3， 如 果 没 有 设置 则 取 环 境 变量 DIB_PYTHON_VERSION 的 值 。 
例如 在 ubuntu Element 中 ， 此 文件 中 的 定义 为 linux-image-generic:， 表 明 在 安装 基于 Ubuntu 的 镜像 时 ， 需 要 在 install 阶 段 安 装 linux-image-generic。 
: README.tst: 一 般 用 来 描述 该 Element 的 功能 以 及 使 用 说 明 等 。 


3.DIB 调 试 


在 制作 镜像 的 过 程 中 可 能 会 遇 到 一 些 问 题 ， 为 了 便于 排查 ，DIB 也 提供 了 调 测 的 方法 。 使 用 break 变 量 可 以 在 特定 的 情况 下 ， 启 动 一 个 shell， 让 你 查看 当前 镜像 的 上 下 文 情况 。break 点 的 设置 方法 一 般 


向 


break-[before|after]-hook name 


其 中 hook_name 是 前 文 介绍 的 8 个 阶段 的 名 称 或 error， 如 果 有 多 个 break 的 点 ， 可 以 用 逗号 隔 开 。 下 面 是 设置 示例 |: 


break=before-block-device,before-finalise 
break-before-pre-install 
break-after-error 


elements 


» Bwapt-conf 


V Y CY YF YYY WW V WOW YYYY YYY NW WM OW M V NW Y 


W apt-preferences 
»wapt-sources 

W baremetal 

W base 

Ml bootloader 

23 cache-url 

W centos-minimal 

Ml centos7 

2x cleanup-kernel-initrd 
W cloud-init 

W cloud-init-datasources 
W cloud-init-disable-resizefs 
23 cloud-init-nocloud 
29 debian 

W debian -minimal 

2x debian-systemd 

Ml debian-upstart 

W debootstrap 

W deploy-baremetal 

MM deploy-kexec 

W deploy-targetcli 

W deploy-tgtadm 

Ml devuser 

2: dhcp-all-interfaces 
W dib-init-system 

2x dib-python 


m L. 


P | dib-run-parts 

» Bmdisable-selinux 

je dkms 

e | docker 

> Budpkg 

» | dracut-network 
| dracut-ramdisk 


> dracut-regenerate 


u F 


图 6-13 ”部 分 DIB 标 准 Elements 
其 中 第 一 个 是 在 block-device 和 finalise 阶 段 前 break， 第 二 个 在 pre-install 阶 段 前 break， 第 三 个 是 在 任何 阶段 只 要 出 错 就 会 break。 
4.Elements 
DIB 提 供 了 非常 多 的 用 于 制作 镜像 的 Elements， 每 个 Element 都 是 镜像 制作 中 的 一 个 完整 功能 ， 如 图 6-13 所 示 是 DIB 提 供 的 部 分 标准 Elements。 


完整 的 Elements 的 使 用 请 参考 官方 文档 [中 。 此 外 ， 也 存在 较 多 第 三 方 项 目 开 发 的 Elements， 如 tripleo-image-elements、tripleo-puppet-elements 等 ， 这 些 Elements 种 类 齐全 、 功 能 丰富 ， 而 且 都 
经 过 充分 的 测试 ， 是 制作 镜像 的 首选 。 


[1] http:/ /docs.openstack.otg/developet/diskimage-buildet/elements.html。 


6.5.3 ”定制 镜像 


使 用 DIB 定 制 镜像 有 以 下 几 种 方式 : 
1) 使 用 DIB 自 带 的 Elements 定 制 镜像 。 
2) 使 用 第 三 方 的 Elements。 


3) 使 用 DIB 工 具 自 带 的 参数 -p (该 参数 指定 的 包 会 在 install 阶 段 执行 完成 后 post-install 阶 段 执 行 前 安装 ) ， 但 是 这 种 方式 有 一 种 局 限 性 ， 即 不 能 跨 系统 ， 因 为 同一 个 软件 包 在 不 同 的 系统 中 名 称 可 能 不 
一 样 。 


4) 自 开发 Flements， 这 个 也 是 使 用 DIB“ 最 高 的 境界 ”， 可 以 完全 根据 自己 的 需要 定制 镜像 ， 灵 活 度 和 自由 度 都 非常 大 ， 但 需要 对 DIB 有 较 深 的 理解 。 
Qu 


由 于 DIB 的 Element 非 常 多 ,而 且 几 乎 没有 哪 一 个 Element 窗 盖 到 DIB 镜 像 制作 的 所 有 8 个 阶段 ， 所 以 读者 在 实现 自 定 义 的 Element 时 ， 尽 量 多 参考 DIB 或 第 三 方 的 Element 实 现 的 例子 ， 本 书 就 不 再 举例 说 


明 。 
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本 章 首先 介绍 了 Nodepool 的 相关 背景 和 安装 过 程 ， 接 着 针对 Nodepoo| 的 原理 ， 分 析 了 Nodepool 的 主要 流程 和 实现 细节 ， 然 后 重点 前 述 了 Nodepoo| 的 配置 并 给 出 了 相关 具体 示例 ， 最 后 简单 描述 了 
镜像 制作 相关 的 原理 。 通 过 对 本 章 内 容 的 学 习 ， 期 望 读者 能 搭建 Nodepool 环 境 并 熟练 使 用 Nodepool。 


本 章 主要 介绍 Jenkins 任 务 产生 的 日 志文 件 的 相关 处 理 ， 包 括 日 志 服 务 器 的 作用 以 及 使 用 方法 等 内 容 。 


7.1 日 志 服 务 器 的 作用 


Jenkins 每 次 Job 运 行 都 会 产生 一 些 日 志文 件 ， 这 些 文 件 在 默认 情况 下 会 保存 在 Jenkins Master 服 务 器 上 。 日 积 月 累 之 后 ，Jenkins Master 上 会 保存 大 量 的 日 志文 件 ， 既 占用 空间 ， 又 可 能 影响 Jenkins 
Master 的 性 能 。 用 户 可 以 在 定义 Job 的 时 候 指定 日 志保 存 的 天 数 或 者 构建 次 数 ， 以 删除 过 期 的 日 志 ， 其 配置 如 图 7-1 所 示 。 


W Discard old builds 


Strategy Log Rotation 


Days to keep builds 


if not empty, build records are only kept up to 
this number of days 


Max # of builds to keep 


If not empty, only up to this number of build 
records are kept 


Days to keep artifacts 


If not empty, artifacts from builds older than 
this number of days will be deleted, but the 
logs, history, reports, etc for the build will be 
kept 


Max # of builds to keep with artifacts 


if not empty, only up to this number of builds 
have their artifacts retained 


图 7-1 Jenkins 丢 弃 旧 的 构建 策略 
Discard old builds 配 置 项 可 以 帮助 Jenkins 减 少 日 志文 件 所 占 的 空间 ， 但是， 如 果 用 户 需 要 查询 这 些 被 删除 的 构建 的 日 志 ， 就 会 遇 到 找 不 到 文件 的 情况 。 


Job 运 行 时 ， 还 可 能 会 动态 产生 一 些 用 户 文件 ， 比 如 用 户 的 代码 中 生成 的 数据 或 文档 ， 这 对 于 用 户 排查 、 确 认 间 题 可 能 是 有 帮助 的 。 这 些 文件 默认 存储 在 运行 Job 的 Slave 上， 如果 Slave 是 动态 的 ， 则 出 
除 Slave 后 这 些 文件 也 就 不 存在 了 ; 如 果 Slave 是 静态 的 ， 则 新 的 Job 运 行 时 很 可 能 覆盖 或 删除 上 一 次 运行 时 产生 的 文件 。 


为 了 持久 地 保存 每 次 Job 运 行 产 生 的 日 志和 用 户 文 件 ，OpenStack Cl/CD 系 统 中 搭建 了 专门 的 日 志 服 务 器 ， 来 实现 这 一 目的 。 


在 OpenStack CI/CD 系 统 中 ， 日 志 服务 器 目前 只 提供 了 通过 Puppet 脚 本 安装 的 这 一 种 方式 。 具 体 的 使 用 方法 请 参考 OpenStack CI Puppet 模 块 文档 1]。 本 书 中 ， 关 于 Puppet 和 脚本 的 使 用 都 在 第 10 章 


中 介绍 。 在 参考 文档 中 ， 首 先 要 通过 system-configl 人 项 目 安装 puppet 模 块 ， 读 者 可 以 查看 该 项 目 库 的 modules.enVv 文 件 获知 安装 的 puppet 模 块 的 列表 ， 其 中 ， 日 志 服 务 器 相关 的 安装 脚本 主要 是 在 
openstack-infra/puppet-openstackci 中 。 读 者 可 以 通过 以 下 方法 克隆 openstack-infra/puppet-openstackci 库 : 


git clone https://git.openstack.org/openstack-infra/puppet-openstackci 


或 者 通过 浏览 器 访问 openstack-infra/puppet-openstackci 的 git 代 码 库 Bl， 在 线 阅 读 该 库 中 日 志 服 务 器 的 相关 代码 ， 包 括 log_server site.pp、logserver.pp 等 。 
日 志 服 务 器 安装 脚本 的 主要 作用 包括 : 

- 创建 HTTP 服 务 站 点 ; 

: 创建 名 为 jenkins 的 用 户 ， 并 使 其 拥有 HTTP 服 务 主 目录 的 写 入 权限 ; 

: 信任 Jenkins 所 使 用 SSH key， 使 Jenkins 获 得 通过 jenkins 用 户 向 日 志 服 务 器 上 SCP 拷 贝 文件 的 权限 。 


安装 之 后 ， 用 户 可 以 从 Jenkins 服 务 器 上 手工 向 日 志 服 务 器 上 传 文件 ， 以 验证 服务 可 用 : 


scp -i SJENKINS SSH PRIVATE KEY FILE -o StrictHostKeyChecking-no $your-log-file \ jenkins8é«fqdn or ip of log server»:/srv/static/logs/ 


上 传 成 功 后 ， 用 户 可 以 使 用 Web 浏 览 器 或 者 curl、wget 等 命令 验证 自己 上 传 的 文件 是 否 存 在 。 例 如 : 


curl  http://«fqdn or ip of log server»/$your-log-file 


[1] https:/ /docs.openstack.org/infra/openstackci/ o 
[2] https:/ /git.openstack.org/cgit/openstack-infra/system-conf igo 
[3] https:/ /git.openstack.org/cgit/openstack-infra/puppet-openstackci o 


7.3 ”使 用 方法 


7.3.1 在 Jenkins 中 使 用 日 志 服 务 器 


日 志 服 务 器 搭建 之 后 ，Jenkins Job 就 可 以 通过 sCP 的 方式 将 日 志和 文件 放置 到 日 志 服务 器 上 保存 了 。 首 先 ，Jenkins 需 要 安装 和 配置 SCP 相 关 的 插件 ， 具 体 方式 请 参考 第 4 章 。 
然后 ， 用 户 在 定义 自己 的 Job 时 ， 在 Job 配 置 中 的 Post-build Actions 部 分 ， 增 加 Publish artifacts to SCP Repository 的 配置 。 下 面 给 出 两 个 例子 进行 说 明 。 


在 图 7-2 中 ， 文 件 来 源 配置 为 空 ， 但 选中 了 “Copy Console Log" 选项， 即 该 Job 运 行 后 会 把 控制 台 的 输出 日 志 通 过 SCP 拷 贝 到 日 志 服 务 器 上 。 


^: Publish artifacts to SCP Repository 


SCP site LogServer 


Select configured SCP host.Check global hudson config for defining connection properties for this 
hosts 


Files to upload 


source 


Destination logs/$LOG PATH [2) 


Copy Console Log W 
Check if we should write the Console Log to the Remote 
Desintation. 


Keep Hierarchy . 


Keep directory hierarchy relative to the workspace when 
copying to the remote destination. 


Copy after failure 


Check if we should copy the source file to the remote 
destination after a build failure.*6 


图 7-2 Jenkins Job 拷 贝 控制 台 日 志 


在 图 7-3 中 ， 文 件 来 源 为 docs_output/**， 即 该 Job 运 行 后 会 把 工作 目录 下 的 docs_output/* 子 目录 的 所 有 文件 通过 SCP 拷 贝 到 日 志 服 务 器 上 。 


— Publish artifacts to SCP Repository 


SCP site LogServer 


Select configured SCP host.Check global hudson config for defining connection properties for this 
hosts 


Files to upload s 


Source docs output/** | 
Destination logs/SLOG PATH e 


Copy Console Log O 


Check if we should write the Console Log to the Remote 
Desintation. 


Keep Hierarchy 


Keep directory hierarchy relative to the workspace when 
copying to the remote destination. 


Copy after failure 


Check if we should copy the source flle to the remote 
destination after a build failure. % 


图 7-3 Jenkins Job 拷 贝 文档 文件 
用 户 可 以 点 击 图 7-3 中 的 Add 按 钮 以 增加 配置 ， 在 一 个 publisher 中 拷贝 多 个 来 源 的 文件 。 
如 果 用 户 使 用 JJB 定 义 Job， 而 不 是 使 用 Jenkins 的 Web 界 面 ， 则 可 以 参考 代码 清 
单 7-1 定 义 自己 的 publisher。 


代码 清单 7-1 使 用 Jenkins publisher 拷 贝 日 志 


- publisher: 
name: console-log 


site: 'LogServer' 


- target: 'logs/S$LOG PATH' 
copy-console: true 
copy-after-failure: true 


- publisher: 
name: upload-docs-draft 
publishers: 


site: 'LogServer' 


- target: 'logs/S$LOG PATH' 
source: 'docs output/**' 
keep-hierarchy: true 
copy-after-failure: true 


7.3 ”使 用 方法 


7.3.1 在 Jenkins 中 使 用 日 志 服 务 器 


日 志 服 务 器 搭建 之 后 ，Jenkins Job 就 可 以 通过 sCP 的 方式 将 日 志和 文件 放置 到 日 志 服务 器 上 保存 了 。 首 先 ，Jenkins 需 要 安装 和 配置 SCP 相 关 的 插件 ， 具 体 方式 请 参考 第 4 章 。 
然后 ， 用 户 在 定义 自己 的 Job 时 ， 在 Job 配 置 中 的 Post-build Actions 部 分 ， 增 加 Publish artifacts to SCP Repository 的 配置 。 下 面 给 出 两 个 例子 进行 说 明 。 


在 图 7-2 中 ， 文 件 来 源 配置 为 空 ， 但 选中 了 “Copy Console Log ”选项 ， 即 该 Job 运 行 后 会 把 控制 台 的 输出 日 志 通 过 SCP 拷 贝 到 日 志 服务 器 上 。 


^: Publish artifacts to SCP Repository 


SCP site LogServer 


Select configured SCP host.Check global hudson config for defining connection properties for this 


hosts 
ES 


Files to upload 
source e 


Destination logs/$LOG PATH e 
Copy Console Log € 
Check if we should write the Console Log to the Remote 
Desintation. 


Keep Hierarchy . 
Keep directory hierarchy relative to the workspace when 
copying to the remote destination. 


Copy after failure W 
Check if we should copy the source file to the remote 
destination after a build failure.% 


图 7-2 Jenkins Job 拷 贝 控制 台 日 志 


在 图 7-3 中 ， 文 件 来 源 为 docs_output/*， 即 该 Job 运 行 后 会 把 工作 目录 下 的 docs_output/* 子 目录 的 所 有 文件 通过 SCP 拷 贝 到 日 志 服 务 器 上 。 


Publish artifacts to SCP Repository 


SCP site | LogServer 
Select configured SCP host Check global hudson config for defining connection properties for this 
hosts 


Files to upload 
source docs output/"* 


Destination logs/sL OG PATH 


Copy Console Log O 
Check if we should write the Console Log to the Remote 
Desintation. 


Keep Hierarchy 


Keep directory hierarchy relative to the workspace when 
copying to the remote destination. 


Copy after failure 
Check if we should copy the source file to the remote 
destination after a build failure.96 


图 7-3 Jenkins Job 拷 贝 文档 文件 
用 户 可 以 点 击 图 7-3 中 的 Add 按 钮 以 增加 配置 ， 在 一 个 publisher 中 拷贝 多 个 来 源 的 文件 。 
如 果 用 户 使 用 JJB 定 义 Job， 而 不 是 使 用 Jenkins 的 Web 界 面 ， 则 可 以 参考 代码 清 
单 7-1 定 义 自 己 的 publisher。 


代码 清单 7-1 使 用 Jenkins publisher 拷 贝 日 志 


- publisher: 
name: console-log 
publishers: 
= SCcp: 
site: 'LogServer' 
files: 
- target: 'logs/SLOG PATH' 
copy-console: true 
copy-after-failure: true 


- publisher: 
name: upload-docs-draft 

publishers: 

= Sp: 
site: 'LogServer' 
files: 

- target: 'logs/$LOG PATH' 
source: 'docs output/**' 
keep-hierarchy: true 
copy-after-failure: true 


7.3.2 如何 获取 日 志文 件 


经 过 了 上 一 节 中 介绍 的 配置 过 程 ，Jenkins Job 在 运行 之 后 ， 会 自动 把 日 志 等 文件 存储 到 日 志 服 务 器 上 。 但 是 ， 使 用 者 还 需要 能 够 获取 到 这 些 文件 ， 而 且 能 够 把 这 些 文件 与 具体 的 Job 或 者 Git/Gerrit 上 的 
patch 对 应 起 来 ， 以 方便 使 用 。 


\ 一 /一 


如 图 7-4 所 示 ， 开 发 者 在 Gerrit 中 提交 了 一 个 patch， 该 patch 在 Gerrit 中 的 ID 为 2776。 该 次 提交 触 上 友 了 所 属 项 目 在 Jenkins 中 定义 的 代码 检查 (check) 的 Job，check Job 运 行 完成 后 把 日 志和 输出 文件 
目录 docs_ output 放 到 了 日 志 服 务 器 上 。 该 Patch 经 过 了 多 次 修改 ， 共 提交 了 6 个 版 本 ， 每 次 提交 都 会 触发 check Job， 并 且 把 日 志 等 文件 放 到 日 志 服 务 器 上 。 该 patch 的 相关 文件 在 日 志 服 务 器 上 的 存储 路 径 
73: http://log.cibook.oz/logs/76/2776/， 如 图 7-4 所 示 。 其 中 ， 第 6 次 提交 对 应 的 日 志文 件 存放 的 路 径 为 : http://log.cibook.oz/logs/76/2776/6/check/ «my job name>/<random_num/>。 这 个 路 
径 中 ， 第 一 级 目录 logs 为 上 一 节 中 Publisher 中 指定 的 Destination 或 target 的 顶层 目录 ， 也 可 以 不 指定 或 者 指定 多 个 层次 ; 第 二 级 目录 76 为 patch ID 的 后 两 位 ; 第 三 级 目录 2776 为 patch ID; 第 四 级 目录 为 
patch 的 版 本 号 ， 即 上 图 中 的 1、2、3、4、5、6; 再 向 下 几 级 目录 分 别 为 Job 类 型 (本 例 中 为 check) 、Job 名 称 、 随 机 数 。 在 该 路 径 下 ， 用 户 可 以 找到 一 个 console.html 文 件 和 一 个 docs_output 目 录 ， 其 


中 console.html 文 件 的 内 容 就 是 Jenkins Job 运 行 时 的 控制 台 输 出 日 志 ，docs_output 目 录 为 Job 的 Publisher 中 指定 的 Source 目 录 ， 被 原样 拷贝 到 了 日 志 服 务 器 上 。 在 check Job 运 行 结束 后 ， 门 控 系 统 Zuul 
会 把 上 述 路 径 填写 到 该 patch 的 comment 中 ， 用 户 点 击 该 HTTP 链 接 就 可 以 看 到 相关 Job 的 运行 结果 及 输出 的 用 户 文件 目录 。 


Y D Index of /76/2776 


2018-04-10 04:25 
2018-04-10 04:30 
2018-04-10 05:10 
2018-04-10 05:27 
2018-04-10 05:31 
2018-04-10 05:44 


图 7-4 日 志 存 储 路 径 


对 于 非 Gerrit patch 触 发 的 Job， 比 如 周期 类 型 的 Job， 在 日 志 服 务 器 上 存在 名 为 periodic、periodic-weekly、periodic-monthly 等 目录 ， 用 户 可 以 到 这 些 目录 中 以 Job 名 称 命名 的 子 目录 下 查找 相关 的 


日 志 。 


7.3.3 ”日志 文件 定期 归档 和 清理 
日 志文 件 存放 之 后 ， 日 志 服务 器 会 定期 执行 log_archive_maintenance.sh 脚 本 对 文件 进行 扫描 检查 ， 对 存放 时 间 较 长 的 文件 进行 归档 和 清理 。 用 户 可 以 登录 到 日 志 服务 器 上 ， 以 root 用 户 执行 crontab-| 
来 查看 相关 的 定时 任务 。 默 认 情况 下 的 操作 策略 为 : 
- 每 星期 定时 运行 归档 操作 ; 
“ 对 扩展 名 为 .fxt、.html 的 文件 和 以 tmp 开 头 的 文件 或 目录 调用 gzib 进 行 压缩 ; 
- 删除 存放 超过 30 天 的 所 有 文件 ; 
删除 空 目 录 。 


如 果 用 户 需要 访问 已 经 被 压缩 但 尚未 被 删除 的 日 志 ， 则 可 以 在 目标 URL 后 面 加 上 .gz 之 后 再 尝试 。 例 如 ， 上 星期 保存 了 一 个 日 志文 件 ， 其 URL 之 前 是 : http://mylogserver/mylogf ile.txt， 在 被 压缩 之 
后 ， 可 以 通过 http://mylogserver/mylogf ile.txt.gz 进 行 访问 。 被 压缩 之 后 又 存放 超过 30 天 的 文件 也 会 被 删除 。 被 删除 后 ， 文 件 将 彻底 无 法 访问 。 

由 于 日 志 服务 器 是 使 用 OpenStack 社 区 提供 的 Puppet 脚 本 安装 的 ， 如 果 需 要 在 安装 时 就 修改 该 定时 归档 和 清理 任务 ， 或 者 禁止 该 任务 ， 则 可 以 在 安装 日 志 服务 器 之 前 ， 对 相关 脚本 进行 修改 ， 包 括 
logserver.pp. log archive_maintenance.sh 等 ， 这 些 脚本 都 在 openstack-infra/puppet-openstackcil1] 库 中 。 如 果 在 日 志 服 务 器 安装 之 后 需要 修改 该 任务 ， 则 可 以 登录 到 日 志 服 务 器 上 ， 以 root 用 户 执行 
crontab-e 编 辑 该 定时 任务 ， 或 者 修改 归档 脚本 的 内 容 ， 该 脚本 存放 的 路 径 为 : /usr/local/sbin/log archive maintenance.sh, 


[1] https:/ /git.openstack.org/cgit/openstack-infra/puppet-openstackci o 
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本 章 对 日 志 服 务 器 的 使 用 方法 进行 了 介绍 。 解 决 了 日 志 的 存储 问题 后 ， 对 数据 进行 分 析 的 方法 请 参考 第 8 章 。 


第 8 草 日 志 分 析 系 统 


第 7 章 提 到 的 日 志 服务 器 解决 了 日 志 的 集中 管理 问题 。 接 下 来 要 面 对 的 状况 是 ， 面 对 如 此 大 量 的 日 志 ， 如 何 高 效 地 查询 、 排 序 和 统计 这 些 日 志 ?” 你 会 发 现 我 们 急需 一 个 日 志 分 析 系 统 。 


Openstack CI/CD 的 日 志 分 析 系 统 是 在 2013 年 开发 的 ， 彼 时 ELK Stack (2016 年 更 名 为 Elastic Stack) 以 其 开源 属性 和 相对 完善 的 功能 ， 成 为 开源 界 实时 日 志 处 理 领 域 的 第 一 选择 。 这 套 日 志 分 析 系 统 
是 一 个 很 好 的 ELK stack 应 用 实例 ， 很 多 地 方 值得 借鉴 与 学 习 。 


Qus 
- 20164. ELK Stack 在 其 5.0 版 本 加 入 Beats (数据 收集 平台 ) 后 更 名 为 Elastic Stack. 


“ 下 文中 提 到 的 日 志 分 析 系 统 如 不 进行 特别 说 明 均 指 OpenStack CI/CD 的 日 志 分 析 系 统 。 


8.1 ELK stack 概况 


最 初 为 大 家 所 知 的 是 ELK。ELK 并 不 是 一 个 软件 ， 而 是 三 款 开 源 软件 的 首 字 母 组 合 : Elasticsearch、Logstash 和 Kibana， 这 三 款 软件 各 司 其 职 ， 完 美 配合 ， 形 成 了 一 套 完 整 的 日 志 分 析 系 统 。 
` Elasticsearch& Æ F Apache Lucene 构 建 的 开源 的 分 布 式 搜索 和 分 析 引 掌 ， 具 有 高 可 伸缩 、 高 可 靠 和 易 管 理 等 特点 。 
Logstash 是 一 个 具有 实时 工作 流 功能 的 开源 数据 收集 引擎 。 它 支持 动态 地 从 各 种 数据 源 搜集 数据 ， 并 对 数据 进行 过 滤 、 分 析 和 统一 格式 等 操作 ， 然 后 存储 到 用 户 指定 的 后 端 存储 区 。 
: Kibana 是 一 个 专门 为 Elasticseatch 服 务 的 开源 分 析 及 可 视 化 平台 ， 用 来 搜索 、 展 示 存 储 在 Elasticseatch 中 的 数据 。 


2013 年 ，Elasticsearch 所 属 的 Elastic.co 公 司 先 后 收购 了 Kibana 和 Logstash，ELK stack (后 面 简 称 为 ELK) 正式 成 为 官方 用 语 。 


8.2 日 志 分 析 系 统 染 构 
日 志 分 析 系统 是 基于 ELK 的 ， 所 以 我 们 先 来 了 解 下 典型 的 ELK 架 构 。 图 8-1 是 典型 的 ELK 架 构 。 
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图 8-1 典型 的 ELK 架 构 


整个 架构 可 以 划分 为 四 个 部 分 。 


1) 数据 监控 与 收集 : 数据 源 所 在 的 系统 中 会 运行 Logstash ( 常 被 称 为 Logstash Shipper) ， 用 来 对 数据 进行 监控 与 收集 ， 最 后 运送 到 Logstash 服 务 器 ( 常 被 称 为 Logstash Indexer) 。 


2) 数据 预 处 理 : 进入 到 Logstash Indexer 的 数据 ， 会 按照 要 求 进行 过 滤 和 修改 转化 为 归 一 化 的 数据 ， 并 送 入 到 Elasticsearch 集 群 进行 存储 。 
3) 数据 索引 与 搜索 : 数据 在 Elasticsearch 中 进行 索引 ， 并 且 Elasticsearch 还 提供 强大 的 搜索 功能 。 
4) 数据 可 视 化 : 通过 Kibana 的 WebUl 界 面 来 查询 和 展示 存储 在 Elasticsearch 中 的 数据 。 


图 8-2 是 日 志 分 析 系 统 架构 。 
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图 8-2 ”日 志 分 析 系统 架构 
日 志 分 析 系 统 的 架构 与 典型 的 ELK 架 构 总 体 上 是 一 致 的 ， 唯 一 的 差别 在 于 数据 的 监控 与 收集 这 部 分 所 采用 的 具体 技术 不 同 。 同 样 ， 日 志 分 析 系 统 也 能 划分 为 四 个 部 分 : 
` Log Pusher (数据 监控 与 收集 ) 
: Logstash Indexer. (数据 预 处 理 ) 
: Elasticsearch 集群 (数据 索引 与 搜索 ) 
: Kibana (数据 可 视 化 ) 
下 面 将 依次 对 这 四 个 部 分 进行 详细 介绍 。 
Gg 


图 8-2 中 的 Subunit Gearman Worker 专 门 负 责 将 门限 测试 结果 和 周期 性 tempest 测 试 结果 存储 到 SQL 数 据 库 。 这 部 分 不 涉及 ELK， 故 本 章 不 对 这 部 分 进行 陈述 。 


8.3 Log Pusher 


Log Pusher 是 OpenStack Infra 团 队 开发 的 。 它 采用 了 Gearman 架 构 ， 随 着 日 志 不 断 增 加 ， 也 能 很 容易 地 进行 水 平 扩展 。 
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8.3.1 处理 流程 


Log Pusher 的 处 理 流程 如 下 : 

1) Log Gearman Client 负 责 监 听 Jenkins ZeroMQ Publisher 发 出 的 Job 构 建 完成 事件 ; 

2) 当 监 听 到 构建 完成 事件 后 ，Log Gearman Client 会 向 Gearman Server 提 交 一 个 推送 日 志文 件 到 Logstash Indexer 的 Gearman 任 务 ; 
3) Gearman Server 将 此 任务 分 发 给 一 个 Log Gearman Worker; 

4) Log Gearman Worker 通 过 HTTP 从 日 志 服 务 器 获取 日 志 ， 然 后 将 日 志 内 容 发 布 到 Logstash Indexer 的 9999 端 口 ; 


5) Logstash Indexer 监 听 9999 端 口 获 得 日 志 信 息 。 


8.3.2 配置 


Log Pusher 的 具体 实现 是 通过 两 个 Python 脚本 来 完成 的 。 这 两 个 脚本 是 开源 的 ， 可 从 参考 地 址 [1 获得 

对 于 使 用 者 来 阅 ， 可 以 先 不 了 解 这 两 个 Python 脚本 的 代码 细节 ， 但 需要 清楚 脚本 使 用 的 配置 文件 ， 根 据 实际 需要 进行 合理 配置 。 
1.jenkins-log-client.yaml 

该 文件 是 log-gearman-client.py 的 配置 文件 ， 内 容 如 代码 清单 8-1 所 示 。 


代码 清单 8-1 jenkins-log-client.yaml 


source-url: http://log.cibook.oz 


zmq- Bue ehre: 
tcp://jenkins.cibook.oz:8888 


subunit-files: [] 


source-files: 
- name: console.html 
retry-get: True 

tags: 

- console 
- name: logs/syslog.txt 
tags: 
- syslog 
- name: logs/libvirtd.txt 
tags: 

- libvirt 


* soutce-utl : 去 文件 所 在 的 服务 器 的 访问 地 址 。 

: zmq-publishers: 监听 的 Jenkins ZeroMQ Publisher 地 址 列表 。 

'source-files: 被 监控 文件 列表 ， 每 个 文件 需 给 定 标 识 列表 属性 tags。 
2.jenkins-log-worker.yaml 
该 文件 是 log-gearman-worker.py 的 配置 文件 。 内 容 如 代码 清单 8-2 所 示 。 
代码 清单 8-2 jenkins-log-worker.yaml 


gearman-host: logstash.cibook.oz 
gearman-port: 4730 

output-host: localhost 
output-port: 9999 

output-mode: tcp 


€t xr 
.. s 


* gearman-host/fegearman-port Z7 J| Æ Gearman setvef 地 址 与 端口 信息 。 
日 志 会 推送 到 <output-mode>://<output-host>:<out-port>， 这 三 个 配置 参数 用 于 与 Logstash 对 接 。 


[1] https://git.openstack.org/cgit/openstack-infra/ puppet-log_processor/tree/f iles/log-geatman-client.py o 


[2] https://git.openstack.org/cgit/openstack-infra/ puppet-log_processor/tree/f iles/log-geatman-worket.py o 


8.4 Logstash Indexer 


日 志 并 不 适合 直接 存储 到 Elasticsearch 中 ， 在 进行 存储 前 我 们 更 希望 对 日 志文 件 进行 一 些 必要 的 预 处 理 ， 如 删除 不 想 要 的 信息 、 修 改 信息 格式 等 ， 这 些 Logstash Indexer 都 能 帮 有 我 们 完成 。 


8.4.1 hello world 


我 们 通过 一 个 简单 的 “hello world” 例 子 来 直观 地 看 看 Logstash 能 干 些 什么 。Logstash 可 以 通过 命令 行 来 运行 : 


bin/logstash -e 'input { stdin { ) ) output { stdout { codec=>rubydebug } }' 


e” 是 Logstash 的 参数 之 一 ， 表 示 从 命令 行 配置 Logstash。 后面 跟着 的 参数 就 是 执行 Logstash 使 用 的 配置 ， 这 个 配置 的 意思 是 : 通过 标准 输入 stdin 读 取 数 据 ， 按 照 设 定编 码 格式 rubydebug 将 结果 


进行 标准 输出 stdout。 
上 面 的 命令 行 执行 确认 后 ， 会 在 屏幕 上 看 到 “Pipeline main started”。 在 命令 提示 符 处 输入 “hello world" : 


hello world 


确认 后 ， 屏 幕 上 会 打印 出 返回 结果 ， 如 代码 清单 8-3 所 示 : 


代码 清单 8-3 ”Logstash 返 回 结果 


"host" => "localhost", 
"Qversion" => "1", 
"Qtimestamp" => 2018-03-28T08:25:07.769Z, 
"message" => "hello world" 


代码 清单 8-3 就 是 最 常见 的 Logstash 输 出 。 
. message: 输入 的 数据 (事件) 。 
- (Qtimestamp: 事件 发 生 的 时 间 玲 。 
.host: 产生 此 事件 的 机 器 。 


简单 来 说 ，Logstash 就 像 一 条 管道 。 一 条 非 格式 化 的 数据 经 过 这 条 管道 后 ， 被 转化 成 了 一 条 格式 化 的 事件 (转化 后 的 数据 在 Logstash 中 也 被 称 作 事件 ) ， 这 样 的 事件 更 便于 人 存储 和 检索 。 


8.4.2 Logstash 管 道 


Logstash 管 道 有 两 个 必 经 的 处 理 环节 ， 即 输入 (input) 和 输出 (output) 。 此 外 ， 还 有 一 个 可 选 的 环节 一 一 过 滤 (fiter) ， 用 于 进行 数据 的 过 滤 和 修改 ，Logstash 的 强大 之 处 也 体现 在 其 过 滤 上 。 
Logstash 还 在 1.3.0 版 本 中 引入 了 Codec 概 念 。 引 入 后 ， 可 以 在 输入 和 输出 时 对 数据 进行 编码 或 解码 处 理 ， 如 图 8-3 所 示 。 
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图 8-3 Logstash 管 道 


数据 的 具体 处 理 是 由 插件 来 完成 的 。Logstash 提 供 了 丰富 的 插件 ， 插 件 按照 功能 可 分 为 输入 插件 、 过 滤器 插件 、 输 出 插件 和 编 解码 器 插件 中 。 用 户 也 可 以 自己 开发 插件 ， 在 此 不 做 歼 述 。 


[1] Logstash Versioned Plugin Reference, https://www.elastic.co/guide/en/logstash-versioned-plugins/current/ o 


8.3 SEMA 


除了 如 hello world 示 例 ， 通 过 -e 来 显示 的 配置 Logstash 管 道 ， 也 可 以 将 配置 固化 在 扩展 名 为 .conf 的 管道 配置 文件 中 ， 通 过 参数 -f 来 告诉 Logstash。 

在 Debian 系 统 中 ， 管 道 配置 文件 的 默认 路 径 是 /etc/logstash/conf.d。Logstash 会 尝试 加 载 这 个 目录 下 所 有 扩展 名 为 .conf 的 文件 ， 拼 接 出 一 个 完整 的 配置 文件 。 
1. 管 道 配置 文件 结构 

Logstash 用 {} 来 定义 区 段 。 管 道 配置 文件 为 要 使 用 到 的 每 种 类 型 的 插件 提供 一 个 独立 的 区 段 ， 如 代码 清单 8-4 所 示 。 


代码 清单 8-4 管道 配置 文件 结构 


input { 
http: //www.hzcourse.com/resource/readBook?path-/openresources/teach ebook/uncompressed/17933/OEBPS/Text/... 


} 


filter { 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/17933/OEBPS/Text/... 


output { 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/17933/OEBPS/Text/... 


每 个 区 段 内 可 以 包含 一 个 或 多 个 插件 区 段 。 需 要 指出 的 是 ， 如 果 在 过 滤器 区 段 内 指定 了 多 个 过 滤器 插件 ， 则 按照 顺序 依次 应 用 。 揪 件 区 段 是 对 具体 插件 的 配置 ， 包 含 插件 名 称 和 该 插件 的 一 组 设置 。 代 
码 清单 8-5 为 在 输入 区 段 配置 了 两 个 输入 插件 (filet) 。 


代码 清单 8-5 ”输入 插件 区 段 配置 


input { 

file { 
path => "/var/log/messages" 
type => "syslog" 


} 


file ( 
path -» "/var/log/apache/access.log" 
type => "apache" 


} 


file 插 件 区 段 内 配置 了 两 个 参数 : 路 径 path 和 类 型 type。 其 含义 如 下 : 

- 监听 /var/log/messages 文 件 ， 标 注 其 类 型 为 syslog。 

监听 /var/log/apache/access.log， 标 注 其 类 型 为 apache。 

插件 的 配置 参数 因 插 件 类 型 而 异 ， 可 查看 对 应 插件 的 文档 。 

2. 配 置 语 法 

Logstash 设 计 了 一 套 自己 的 DSL (Domain Specific Language) 。 除 了 上 面 提 到 的 区 段 ， 其 他 语法 还 包括 : 
“ 数据 类 型 

. 字段 引用 

“ 条 件 判 断 

语法 细节 可 以 参看 官方 文档 趾 ， 在 此 不 做 获 述 。 


[1] Configuring Logstash, https:/ /www.elastic.co/guide/en/logstash/current/conf iguration.html o 


84.4 管道 配置 实例 


Logstash 在 使 用 上 的 一 个 重点 是 如 何 配置 管道 配置 文件 ， 下 面 介绍 一 下 在 日 志 分 析 系 统 使 用 的 管道 配置 文件 。 
1. 输 入 配置 文件 (input.conf) 
输入 配置 文件 内 容 如 代码 清单 8-6 所 示 。 


代码 清单 8-6 ”输入 配置 文件 


input { 
tcp 1 
host => "localhost" 
port => 9999 


codec => json lines () 
type => "jenkins" 
- host 和 port 与 代码 清单 8-2 jenkins-log-worker.yaml 中 的 output-host 和 output-port 必 须 保持 一 致 ， 否 则 无 法 接收 到 日 志 信 息 。 
. 对 收 到 的 日 志 使 用 编 解码 插件 json_lines 进 行 解码 (codec=>json_lines{}) ， 并 标记 日 志 类 型 为 jenkins (type=>"jenkins") 。 
2. 输 出 配置 文件 (output.conf) 
输出 配置 文件 内 容 如 代码 清单 8-7 所 示 : 


代码 清单 8-7 输出 配置 文件 


output { 

elasticsearch { 
hosts => ['es.cibook.oz:9200'] 
manage template => false 
false timeout -» 300 


这 里 后 端 存 储 选择 的 是 elasticsearch ， 因 此 使 用 的 输出 插件 是 elasticsearch。 

< hosts: 对 接 的 是 elasticsearch 节 点 地 址 列表 。 

manage_template: 此 处 配置 为 false， 表 示 关 闭 Logstash 自动 创建 索引 模板 功能 。 

timeout; 发 送 到 Elasticsearch 的 请 求 响应 超时 时 间 。 超 时 后 ， 请 求 会 重 发 。 

3. 过 滤 配 置 文件 (openstack-filters.conf) 

过 滤 配 置 文件 描述 了 对 日 志 内 容 处 理 的 步骤 ， 可 参考 相关 地 址 1。 根据 日 志 的 tags 值 (在 jenkins-log-client.yaml 中 定义 ) 不 同 ， 进 行 不 同 的 过 滤 处 理 。 
以 对 console 日 志 的 处 理 这 段 代码 为 例 进行 说 明 ， 如 代码 清单 8-8 所 示 。 


代码 清单 8-8 ”console 日 志 处 理 


if "console" in [tags] or "console.html" in [tags] { 
if [message] == "<pre>" or [message] == "<pre>" ( 


drop {} 


multiline { 
negate => true 
pattern => "^%{TIMESTAMP ISO8601] MIS 
what => "previous" 加 
stream identity => "$(host].$(filename]" 


} 
grok { 
# Do multiline matching as the above mutliline filter may add newlines 
# to the log messages. 
match => { "message" => "(?m)^%{TIMESTAMP_IS0O8601:logdate} \| %{GREEDYDATA: 
logmessage}" } 
add field => { "received at" => "%{@timestamp}" } 


} 


1) tags 字 段 包含 console 或 console.html 的 事件 将 进入 这 个 处 理 分 支 。 
2) 首先 使 用 过 滤器 插件 drop 丢 弃 message 字 上段 是 <pre> 或 </pre> 的 事件 。 


3) 接 下 来 是 编 解码 插件 multiline。 有 时 调试 类 日 志 会 为 一 个 事件 打印 多 行内 容 ， 此 插件 能 将 多 行 消息 合并 到 一 个 Logstash 事 件 中 。 事 件 的 message 字 段 与 Pattern 进行 匹配 ， 如 果 匹 配 不 成 功 ， 表 明 是 
多 行 消息 中 的 一 行 ， 与 上 一 行进 行 合 并 ， 如 果 匹 配 成 功 ， 则 不 进行 合并 操作 。 


4) 最 后 使 用 grok 插 件 。 这 个 插件 是 Logstash 最 重要 的 插件 。 事 件 的 message 字 有 段 与 natch 中 给 定 的 正则 表达 式 进行 匹配 ， 匹 配 到 TIMESTAMP ISO8601 的 部 分 赋值 给 iogdate 字 段 ， 匹 配 到 
GREEDYDATA 的 部 分 赋值 给 logmessage 字 段 ， 这 两 个 字段 会 放 入 最 后 的 输出 结果 中 。 此 外 ， 通 过 配置 参数 add f ield 往 输出 结果 中 加 入 received at 字段 ， 其 值 为 事件 发 生 的 时 间 戳 。 


CR 
wu 
TIMESTAMP_ISO8601 和 GREEDYDATA 为 官方 提供 预定 义 的 gtrok 表 达 式 ， 具 体 定义 可 以 在 抽 ogstash/vendor/bundle/jruby/2.3.0/gems/logstash-patterns-core-4.1.2/patterns/ 目 录 下 查找 。 


[1] https://github.com/openstack-infra/logstash-f ilters/blob/master/f ilters/openstack-f ilters.conf. 


8.5 Elasticsearch 


预 处 理 好 的 日 志 事 件 被 送 入 Elasticsearch 进 行 索 引 。Elasticsearch 使 用 Java 开 发 并 使 用 Lucene 作 为 其 核心 来 实现 所 有 索引 和 搜索 的 功能 。 而 且 它 还 提供 了 RESTfull API 接 口 来 隐藏 Lucene 的 复杂 性 。 


Elasticsearch 上 手 非常 简单 。 它 提供 了 很 好 的 默认 设置 ， 对 初学 者 而 言 ， 它 开 箱 即 用 ， 无 须 立 马 面 对 复杂 的 理论 。 本 节 会 涵盖 Elasticsearch 的 核心 概念 、 如 何 进行 索引 和 简单 的 搜索 及 使 用 中 涉及 的 重 
要 配置 等 内 容 。 


A Ed 


使 用 RESTful API 和 Elasticseatch 进 行 通信 ， 默 认 端 口 02200， 也 可 在 配置 文件 elastic-seatch.yml 中 进行 修改 。 你 可 以 用 浏览 器 访问 Elasticseatch， 在 下 文中 你 将 看 到 也 能 使 用 cutl 命 令 来 和 Elasticseatch 交 互 。 


8.5.1. 面 喇 文 档 的 数据 库 


Elasticsearch 是 面向 文档 的 数据 库 。 它 的 存储 对 象 是 文档 。 简 单 来 说 ， 文 档 是 序列 化 的 JSON (JavaScript Object Notation) 数据 ， 代 码 清单 8-9 是 一 个 JSON 文 档 ， 它 代表 了 一 个 用 户 对 象 。 


代码 清单 8-9 ” JSON 文档 


"email": "john@smith.com", 

"first name": "John", 

"last name": "Smith", 

"age": 25, 

"interests": [ "dolphins", "whales" ], 
"about": "I love to go rock climbing." 
"join date": "2014/05/01" 


文档 里 的 基本 单元 是 字段 (field) ， 如 "last name";" Smith", 
在 我 们 把 这 个 JSON 文 档 索 引 到 Elasticsearch 之 前 ， 还 需要 了 解 两 个 概念 : 索引 (Index) 和 类 型 (Type) 。 


在 Elasticsearch 中 ， 文 档 属于 一 种 类 型 ， 类 型 存在 于 索引 中 。 它 们 之 间 的 关系 如 图 8-4 所 示 。 


Index 1 


Document 1 Document 3 


Document 2 Document 4 


图 8-4 索引 、 类 型 和 文档 的 关系 


所 以 在 索引 文档 之 前 ， 我 们 需要 确定 将 文档 放 入 哪个 索引 的 哪个 类 型 下 。 


8.5.2 索引、 检索 和 搜索 


1. 索 引文 档 
现在 我 们 来 索引 代码 清单 8-9 的 这 个 JSJON 文 档 。 实 际 操 作 如 代码 清单 8-10 所 示 。 


代码 清单 8-10 ”索引 文档 


curl -XPUT 'localhost:9200/users/info/1l' -d ' 
{ 


"email": "john8smith.com", 

"first name": "John", 

"last name": "Smith", 

"age": 25, 

"interests": [ "dolphins", "whales" ], 
"about": "I love to go rock climbing.", 
"join date": "2014/05/01" 


} 1 


URL 中 的 /users/info/1 表 示 文 档 归 属 在 索引 users 的 类 型 info 下 ， 且 唯一 编号 为 |。 其中， 文档 的 唯一 编号 可 以 自己 指定 ， 也 可 让 系统 自动 分 配 。 


现在 我 们 来 回 看 代码 清单 8-7， 也 许 你 会 发 现 ， 在 Logstash 输 出 插件 elasticsearch 中 没有 出 现 索 引 和 类 型 的 信息 ， 那 么 日 志 被 存 到 哪个 索引 和 哪个 类 型 了 呢 ?Elasticsearch 输 出 插件 对 应 索引 和 类 型 的 
配置 参数 是 index 和 document type, 


index: 使 用 了 默认 值 logstash-%{+YYYY.MM.dd} ， 也 就 是 说 一 天 中 的 所 有 日 志 都 索引 到 同一 个 索引 下 ， 索 引 名 与 日 期 绑 定 。 

: document type: 如 果 没 有 配置 ， 对 于 Elasticseatch 5.0 及 以 下 版 本 ， 优 先 使 用 事件 的 type 字 段 ， 如 果 没 有 配置 type 字 段 ， 则 使 用 doc; 对 于 Elasticseatch 6.0 及 以 上 版 本 ， 则 直接 使 用 doc。 
2. 检 索 文 档 
在 Elasticsearch 中 检索 出 数据 也 非常 简单 ， 实 际 操 作 如 代码 清单 8-11 所 示 。 


代码 清单 8-11 检索 文档 


$ curl -XGET 'localhost:9200/users/info/1' 
{ 


" index" : "users", 
Ww type" : "info" 
1 Ww i 


"first name" : "John", 


"age" : 25, 

"interests" : [ 
"dolphins", 
"whales" 


l; 


"about" : "I love to go rock climbing.", 
"join date" : "2014/05/01" 
) 


爹 索 时 使 用 的 URL 与 刚刚 创建 时 的 一 样 ， 只 是 方法 从 PUT 变 成 了 GET。 从 返回 的 信息 ， 我 们 可 以 看 到 除了 放 在 _source 中 原 有 的 JSON 文 档 ， 还 包含 了 一 些 文档 的 元 数据 (metadata) 。 


: index: 文档 的 索引 。 
| _type: 文档 的 类 型 。 
| dd: 文档 的 唯一 编号 。 
: version: 文档 版 本 信息 ， 记 录 文 档 变更 次 数 。 
3 .搜索 文档 
下 面 我 们 来 看 看 如 何 使 用 Elasticsearch 进 行 搜索 。 
第 一 个 尝试 的 是 最 简单 的 搜索 一 一 搜索 所 有 用 户 。 搜 索 使 用 的 是 _ search 接 口 ， 实 际 操作 如 代码 清单 8-12 所 示 。 


代码 清单 8-12 ”搜索 所 有 用 户 


$ curl -XGET 'localhost:9200/users/info/ search' 
{ 
"Look" : 3, 
"timed out" : false, 
" shards" : { 
"total" : 5, 
"successful" : 5, 
"skipped" : 0, 
"failed" : 0 
), 
"hits" i ( 
"total" : 2, 
"max score" : 1.0, 
"hits" : [ 
{ 
" index" : "users", 
n type" : "T info" " 
"id" S "o" P 
" Score" $ 1.0, 
" source" : 1 
"email" : "jane8smith.com", 
"first name" : "Jane", 
"last name" : "Smith", 
"age" : 32, 
"about" : "I like to collect rock albums", 
"interests" : [ 
"music" 
l; 
"join date" : "2017/06/01" 
} 
), 
{ 
" index" : "users", 
" type" : "info" P 
" id" : "T T M 
" score" : 1.0, 
" source" : { 
"email" : "john8smith.com", 
"first name" : "John", 
"last name" : "Smith", 
"age" : 25, 
"interests" : [ 
"dolphins", 
"whales" 
l; 
"about" : "I love to go rock climbing.", 
"join date" : "2014/05/01" 
} 
} 
| 
} 
} 


返回 结果 中 各 项 含义 如 下 。 

took: 执行 搜索 所 耗费 的 时 间 ， 单 位 为 毫秒 。 

: timeout: 查询 是 否 超时 。 通 常 ， 搜 索 请 求 不 会 超时 。 如 果 相 比 完 整 的 结果 ， 你 更 需要 的 是 快速 的 响应 时 间 ， 你 可 以 指定 在 搜索 请 求 的 URL 里 指定 timeout 值 ， 例 如 : 
Elasticsearch 会 尽 可 能 地 返回 指定 时 间 内 它 所 查 到 的 内 容 。 

: shards: 参与 查询 分 片 的 总 数 。 分 片 的 内 容 可 参见 8.5.4 节 。 


: hits: 返回 结果 中 最 重要 的 内 容 就 是 hits 它 包含 了 匹配 文档 的 总 数 (hits.total:2) ， 还 包含 了 文档 本 身 ， 被 放 在 数组 hits.hits 中 。 每 个 匹配 的 搜索 结果 还 有 一 个 _score 字 段 。 这 个 是 相关 性 评分 ， 这 个 数值 
表示 当前 文档 与 查询 的 匹配 程度 。 通 常 来 说 ， 搜 索 结 果 会 先 返 回 最 匹配 的 文档 ， 也 就 是 hits.hits 数 组 会 按照 _scote 的 高 低 进行 排序 。hits.max_scote 会 显示 所 有 匹配 文档 中 的 _scote 的 最 大 值 。 


接 下 来 进行 一 个 具体 点 的 搜索 一 一 搜索 所 有 姓氏 为 Smith 的 用 户 ， 如 代码 清单 8-13 所 示 。 


代码 清单 8-13 ”使 用 查询 短语 进行 搜索 


$ curl -XGET 'localhost:9200/users/info/ search?q-last name:Smith' 


http: //www.hzcourse.com/resource/readBook?path-/openresources/teach ebook/uncompressed/17933/OEBPS/Text/... 部 分 内 容 省 略 http://www.hzcourse.com/resource/readBook?path=/openr: 
Qo 
"total" : 2, 
"max score" : 0.2876821, 
"hits" z [ 
{ 
" index": "users", 
" type" : "info", 
ud id" : n ud 7 


" score": 0.2876821, 


| Source": { 


"email": "jane8smith.com", 
"first name": "Jane", 
"last name": "Smith", 
"age": 32, 
"about": "I like to collect rock albums", 
"interests": [ "music" ], 
"join date": "2017/06/01" 
} 
), 
{ 
" index" : "users", 
" type" : "T info" 7 
"iq" : "T 1 "o 
" score" : 0.2876821, 
" source" : 
"email" : "john8smith.com", 


"first name" : "John", 


"last name" : "Smith", 

"age" : 25, 

"interests" : [ 

"dolphins", 

"whales" 
l, 
"about" : "I love to go rock climbing.", 
"join date" : "2014/05/01" 


} 


这 里 用 到 的 是 精简 版 的 搜索 ， 使 用 的 是 查询 语句 (query string) ， 即 URL 中 的 q=last_name:Smith。 


Elasticsearch 还 提供 了 一 个 使 用 SON 表 示 请 求 体 (request body) ， 这 种 富 搜索 语言 叫 作 结构 化 查询 语句 (DSL) ， 它 支持 构建 更 加 复杂 和 健壮 的 查询 。 下 面 我 们 使 用 DSL 进 行 一 个 稍微 复杂 点 的 搜 
索 ， 依 旧 是 搜索 姓氏 为 Smith 的 用 户 ， 但 这 次 只 需要 搜索 年 龄 大 于 30 的 ， 如 代码 清单 8-14 所 示 。 


代码 清单 8-14 ”使 用 DSL 搜 索 


$ curl -XGET 'localhost:9200/users/info/ search?' -d ' 


{ 


"query" : { 
"bool": { 
"must": ( 
"match" : ( 
"last name": "Smith" 
} 
), 
"filter" i 
"range" : { 
"age" : { "az 30 ) 
} 
} 
} 
} 
FI 
{ 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/17933/OEBPS/Text/... 部 分 内 容 省 略 http://www.hzcourse.com/resource/readBook?path=/openr: 
"Arts" c 
"total" : 1, 
"max score" : 0.2876821, 
"hits" : [ 
{ 
" index" : "users", 
"T type" : "info", 
"uam : ON 
" score" : 0.2876821, 
" Source" : ( 
"email" : "jane8smith.com", 
"first name" : "Jane", 
"last name" : "Smith", 
"age" : 32, 
"about" : "I like to collect rock albums", 
"interests" : [ 
"music" 
l; 
"join date" : "2017/06/01" 


VÀ 


现在 返回 结果 中 只 会 显示 32 岁 的 名 为 Jane Smith 的 用 户 。 
最 后 一 个 示例 ， 我 们 介绍 下 Elasticsearch 的 全 文 搜索 功能 ， 搜 索 所 有 喜欢 rock climbing 的 用 户 ， 如 代码 清单 8-15 所 示 。 


代码 清单 8-15 全文 搜索 


$ curl -XGET 'localhost:9200/users/info/ search' -d ' 
{ 


ud query" : { 
"match": ( 
"about": "rock climbing" 


} 


http: //www.hzcourse.com/resource/readBook?path-/openresources/teach ebook/uncompressed/17933/0EBPS/Text/... 部 分 内 容 省 略 http://www.hzcourse.com/resource/readBook?path=/openr: 
"buts" sd 
"total" $2; 
"max score" : 0.5753042, 
"Biete | 
{ 
" index" : "users", 
ud type T : Ww info" P 
wig" S "IU 7 
" score" : 0.5753042, 
" source" : { 
"email" : "john8smith.com", 
"first name" : "John", 
"last name" : "Smith", 
"age" : 25, 
"interests" : [ 
"dolphins", 
"whales" 
l; 
"about" : "I love to go rock climbing.", 
"join date" : "2014/05/01" 
} 
), 
{ 
" index" : "users", 
ud type" : ud info" " 
iid" . non > 
" score" : 0.2876821, 
" source" : { 
"email" : "jane8smith.com", 
"first name" : "Jane", 
"last name" : "Smith", 
"age" : 32, 
"about" : "I like to collect rock albums", 
"interests" : [ 
"music" 


"join date" : "2017/06/01" 


Elasticsearch 会 通过 相关 性 来 排序 搜索 结果 。 在 第 一 个 结果 中 ，John Smith 的 about 字 段 明 确 地 写 到 了 rock climbing, mane Smith 的 about 字 段 中 则 提 到 了 rock， 但 是 并 没有 提 及 climbing， 同 
样 作 为 匹配 结果 ， 但 后 者 的 _score 就 要 比 前 者 的 低 。 


如 果 你 想 搜 索 的 其 实 是 “rock climbing” 这 个 短语 ， 可 以 使 用 match_pharse 来 查询 ， 如 代码 清单 8-16 所 示 。 


代码 清单 8-16 ”短语 搜索 


$ curl -XGET 'localhost:9200/users/info/ search' -d ' 


ud query" : { 
"match phrase": { 
"about": "rock climbing" 
} 
} 
} ' 


这 时 就 只 会 返回 用 户 John Smith 的 信息 。 


这 里 介绍 的 搜索 内 容 ， 仪 仅 是 浅 党 轻 止 ， 考 虑 到 篇 幅 原 因 ， 更 多 的 搜索 特性 都 未 提 及 ， 如 果 你 感 兴趣 ， 可 以 查阅 相关 文档 。 不 过 总 体 来 说 ，Elasticsearch 确 实 很 容易 使 用 ， 不 需要 特别 的 配置 ， 只 要 往 
Elasticsearch 里 添加 数据 就 可 以 开始 你 的 搜索 之 旅 了 。 


8.5.3 “二 点 和 集群 
一 个 运行 Elasticsearch 实 例 的 服务 器 可 称 为 一 个 节点 (Node) 。 每 个 节点 都 有 自己 的 节点 名 称 (node.name) ， 默 认 情况 下 该 名 称 是 在 启动 时 分 配给 节点 的 随机 通用 唯一 标识 符 (UUID) ， 也 可 以 自 
定义 节点 名 称 。 


集群 (Cluster) 由 一 个 或 者 多 个 配置 相同 集群 名 称 (cluster.name) 的 节点 组 成 ， 默 认 情 况 下 单个 节点 是 只 有 一 个 节点 的 特殊 集群 。 对 用 户 来 说 ， 节 点 加 入 和 退出 集群 非常 简单 ， 只 需要 修改 节点 的 
cluster.name 配 置 即 可 。 请 注意 ， 一 个 节点 同一 时 间 下 只 能 加 入 一 个 集群 ， 集 群 之 间 的 名 称 不 能 相同 。 


1. 主 节点 和 数据 节点 


集群 中 的 一 个 节点 会 被 选举 为 主 节点 (master node) 。 主 节点 是 集群 的 最 高 统治 者 ， 负 责 集群 相关 的 操作 ， 例 如 创建 或 删除 索引 、 增 加 或 移 除 节点 等 。 集 群 中 负责 数据 处 理 的 节点 可 称 为 数据 节点 ， 
例如 索引 和 搜索 文档 。 一 个 集群 中 拥有 的 数据 节点 越 多 ， 处 理 数据 的 能 力 就 越 强 。 


默认 配置 下 ， 节 点 是 主 节点 候选 节点 ， 都 有 资格 参与 主 节点 选举 ， 也 都 可 以 作为 数据 节点 。 


node.master: true 
node.data: true 


上 述 两 个 配置 可 在 配置 文件 elasticsearch.yml 中 找到 。 如 果 不 希望 节点 参与 主 节 点 选举 ， 只 需 将 node.master 配 置 为 false。 如 果 不 希望 节点 作为 数据 节点 ， 只 需 将 节点 的 node.data 配 置 为 false。 对 于 
大 规模 的 集群 ， 需 要 考虑 分 离 出 一 些 节 点 作为 专用 的 主 节点 候选 的 节点 。 


2. 集 群 健康 状态 


集群 健康 状态 有 绿色 、 黄 色 或 红色 三 种 状态 值 。 绿 色 代 表 一 切 正 常 ， 集 群 功能 齐全 ;黄色 代表 所 有 的 数据 都 是 可 用 的 ， 集 群 功能 齐全 ， 但 是 某 些 副本 (可 参考 8.5.4 节 ) 没有 被 分 配 ; 红色 则 代表 因为 某 
些 原因 ， 某 些 数 据 不 可 用 ， 但 集群 仍然 部 分 可 用 ( 它 仍 然 会 响应 部 分 搜索 请 求 ) ， 但 是 需要 尽快 修复 它 ， 因 为 有 数据 丢失 。 


查询 集群 健康 状态 如 代码 清单 8-17 所 示 。 


代码 清单 8-17 ”查询 集群 健康 状态 


$ curl -XGET 'http://localhost:9200/ cluster/health?pretty-true' 
{ 


"Cluster name" : "elasticsearch", 


"number of nodes" : 1, 
"number of data nodes" : 1, 
"active primary shards" : 0, 
"active shards" : 0, 

"relocating shards" : O0, 
"initializing shards" : 0, 
"unassigned shards" : O0, 
"delayed unassigned shards" : O0, 
"number of pending tasks" : O0, 


"number of in flight fetch" : 0, 
"task max waiting in queue millis" : O0, 
"active shards percent as number" : 100.0 


该 返回 结果 显示 集群 名 为 elasticsearch 的 集群 状态 是 green。 


8.5.4. 系 引 分 片 和 率 引 副本 


实际 上 ， 索 引 只 是 一 个 逻辑 命名 空间 (logical namespace) ， 它 指向 一 个 或 多 个 的 索引 分 片 (Shards) 。 分 片 才 是 存储 文档 的 实际 物理 区 域 。 
索引 副本 (Replica) ， 即 为 达 引 创建 一 份 或 多 份 副 本 拷贝 。 索 引 副 本 一 方面 提高 了 数据 的 可 靠 性 ; 另 一 方面 ， 在 搜索 索引 时 ， 可 以 在 副本 上 并 行进 行 ， 扩 展 了 搜索 量 /吞吐 量 。 


从 索引 副本 的 角度 ， 分 片 分 为 主 分 片 和 副本 分 片 。Elasticsearch 在 分 配 分 片 到 节点 时 遵循 主 分 片 与 其 副本 分 片 不 分 配 在 同一 节点 的 原则 。 这 是 因为 如 果 分 配 在 同一 节点 ， 一 旦 节点 故障 ， 主 分 片 和 副本 
分 片 都 可 能 丢失 无 法 找 回 ， 导 致 数据 丢失 。 


主 分 片 的 数量 在 索引 创建 后 就 固定 下 来 了 ， 但 是 副本 分 片 的 数量 可 以 随时 改变 。 默 认 配 置 下 创建 一 个 索引 ， 其 索引 的 分 片 数 为 5 (number of shards=5) ， 索 引 副 本 数量 为 
1 (number_of_replicas=1) ， 这 个 索引 总 共 拥 有 的 分 片 数 为 10， 即 5 个 主 分 片 +5 个 副本 分 片 。 


代码 清单 8-18 创 建 了 一 个 名 为 jenkins 的 索引 ， 并 将 索引 的 分 片 数 设置 为 3。 


代码 清单 8-18 ”创建 索引 


curl -XPUT 'localhost:9200/jenkins' -d ' 
{ 


"settings" : ( 
"number of shards" : 3, 
"number of replicas": 1 


) 1 


在 一 个 有 三 个 节点 的 集群 里 ， 这 个 索引 的 分 片 的 分 配 可 能 如 图 8-5 所 示 。 


Node 1 (Master) 


图 8-5 ”分 片 在 节点 中 的 分 配 


8.5.5 “分 布 式 特性 


Elasticsearch 天 生 支 持 分 布 式 。 同 时 ， 它 尽 可 能 地 屏 菩 了 分 布 式 系统 的 复杂 性 ， 很 多 分 布 式 的 操作 都 是 由 底层 自动 完成 的 ， 对 用 户 完全 透明 ， 例 如 : 
. 分 配 文档 到 分 片 中 。 

. 复制 分 片 作 为 数据 宛 余 备份 。 

. 按 节点 数 来 均衡 分 配 分 片 。 

当 新 增 或 删除 一 个 节点 时 ， 集 群 都 会 重新 平均 分 配 所 有 的 数据 。 

. 将 集群 中 任 一 节点 的 请 求 路 由 到 存 有 相关 数据 的 节点 。 


即使 完全 不 了 解 内 部 机 制 也 不 妨碍 你 使 用 Elasticsearch， 但 是 了 解 这 些 机 制 的 细节 将 从 另 一 个 角度 帮助 你 了 解 更 完整 的 Elasticsearch 知 识 。 考 虑 到 篇 幅 的 原因 ， 这 些 内 部 机 制 不 在 此 展开 ， 如 果 你 感 兴 
趣 ， 可 以 翻阅 相关 的 文档 资料 。 


8.5.6 配置 Elasticsearch 


以 Debian 系 统 为 例 ，Elasticsearch 配 置 文件 的 默认 配置 目录 为 /etc/elasticsearch。 目 录 位 置 可 以 通过 修改 环境 变量 ES_PATH_CONF 来 修改 配置 目录 ， 可 以 在 /etc/default/elasticsearch 中 修改 该 变 


本 节 开 始 就 提 到 Elasticsearch 提 供 了 很 好 的 默认 设置 ， 开 箱 即 用 。 在 实际 的 生产 环境 中 ， 个 别 配置 可 能 需要 根据 实际 情况 进行 调整 。 


1. 路 径 配 置 


默认 情况 下 ，Elasticsearch 会 把 数据 和 日 志 放 在 安装 目录 下 。 如 果 使 用 默认 路 径 ， 那 么 重 装 或 升级 Elasticsearch 时 ， 这 些 数据 和 日 志 被 删除 的 风险 很 高 。 因 此 ， 在 生产 环境 中 ， 需 要 更 改 数据 和 日 志 
件 夹 的 位 置 : 


path.data: /var/data/elasticsearch 
path.logs: /var/log/elasticsearch 


path.data 设 置 可 以 设置 为 多 个 路 径 ， 在 这 种 情况 下 ， 所 有 路 径 将 用 于 存储 数据 : 


path.data: 

- /mnt/elasticsearch 1 
- /mnt/elasticsearch 2 
- /mnt/elasticsearch 3 


以 上 配置 存在 与 elasticsearch.ym| 中 。 


在 生产 环境 中 ， 应 该 将 这 两 个 名 称 改 为 描述 集群 /节点 用 途 的 名 称 更 为 恰当 。 


cluster.name: jenkins-logging 
node.name: jenkins 001 data 


确保 不 要 在 不 同 的 环境 中 使 用 相同 的 集群 名 称 ， 否 则 会 导致 节点 加 入 错误 的 集群 。 以 上 配置 可 在 配置 文件 elasticsearch.yml 中 找到 |。 
3. 最 小 主 节点 数 
该 配置 可 在 配置 文件 elasticsearch.yml 中 找到 。 这 个 配置 是 为 了 防止 脑 裂 。 


集群 主 节点 确定 后 ， 主 节点 会 建立 一 个 内 部 ping 机 制 来 监控 集群 内 的 其 他 节点 是 否 在 线 。 当 集群 中 一 个 或 多 个 节点 与 主 节点 失 联 ， 这 些 节点 会 重新 选举 出 一 个 新 的 主 节点 ， 这 样 就 出 现 一 个 集群 同时 存 


在 两 个 主 节 点 ， 这 就 是 脑 裂 。 脑 裂 会 导致 数据 的 丢失 。 配 置 最 小 主 节点 数 就 是 告诉 Elasticsearch， 当 没有 足够 的 主 节 点 候选 节点 时 ， 不 要 进行 主 节 点 选举 ， 防 止 脑 裂 。 


这 个 配置 的 数值 必须 设置 为 主 节点 候选 节点 个 数 的 法 定 多 数 ， 即 ( 主 节点 候选 节点 个 数 /2+1) 。 例 如 ， 集 群 中 有 10 个 主 节点 候选 节点 ， 那 么 法 定 多 数 就 是 6。 


discovery.zen.minimum master nodes: 6 


4. 集 群 恢复 相关 配置 


当 集 群 重启 时 ， 集 群 恢复 相关 的 配置 项 会 影响 分 片 恢复 的 表现 。 首 先 来 了 解 下 如 果 什 么 也 不 配置 将 会 发 生 什 么 。 


假设 你 的 集群 有 10 个 节点 ， 每 个 节点 只 保存 一 个 分 片 。 你 进行 了 一 次 重启 集群 的 操作 ， 愉 巧 出 现 了 6 个 节点 已 经 启动 ， 还 有 4 个 还 没 启动 的 场景 。 在 线 的 6 个 节点 相互 通信 ， 选 出 一 个 master， 从 而 形成 
一 个 集群 。 它 们 注意 到 数据 不 再 均匀 分 布 ， 因 为 有 4 个 节点 还 在 启动 中 ， 所 以 它们 之 间 会 立即 启动 分 片 复 制 。 最 后 ， 其 他 4 个 节点 启动 完成 加 入 了 和 集群， 这 些 节点 会 发 现 它们 的 数据 正在 被 复制 到 其 他 节点 ， 
所 以 它们 删除 本 地 数据 ， 然 后 整个 集群 重新 进行 平衡 (因为 集群 的 大 小 已 经 从 6 变 成 了 10) 。 在 整个 过 程 中 ， 节 点 会 消耗 磁盘 和 网 络 带 宽 ， 来 回 移动 数据 。 对 于 数据 量 很 大 的 集群 ， 这 种 无 用 的 数据 传输 需 


要 很 长 时 间 。 如 果 等 待 所 有 的 节点 重启 好 了 ， 整 个 集群 再 上 线 ， 那 么 所 有 的 本 地 数据 都 不 需要 移动 。 


Elasticsearch 为 了 缓解 这 个 问题 ， 设 置 了 一 些 配 置 。 首 先 ， 设 置 了 一 个 阅 值 : 


gateway.recover after nodes: 8 


这 个 配置 的 意思 是 : 当 集 群 中 有 多 少 个 节点 在 线 时 ， 恢 复 将 启动 。 


然后 告诉 Elasticsearch 集 群 中 应 该 有 多 少 个 节点 ， 我 们 愿意 为 剩 下 的 启动 中 的 节点 等 待 多 久 : 


gateway.expected nodes: 10 
gateway.recover after time: 5m 


这 三 个 配置 加 在 一 起 后 意味 着 : 

1) 首先 等 待 8 个 节点 上 线 。 

2) 当 条 件 1 满 足 后 ， 恢 复 将 启动 。 等 待 集群 节点 到 达 10 个 或 者 等 待 5 分 钟 ， 两 个 条 件 中 任 一 满足 ， 立 即 启动 恢复 。 
以 上 配置 可 在 配置 文件 elasticsearch.yml 中 找到 。 

5. 单 播 与 组 播 


生产 环境 中 ，Elasticsearch 会 配置 为 单 播发 现 ， 而 不 是 组 播发 现 ， 以 防止 节点 无 意 中 加 入 集群 。 


discovery.zen.ping.multicast.enabled: false 


使 用 单 播 ， 需 要 为 Elasticsearch 实 例 提供 一 些 它 可 以 去 尝试 连接 的 节点 列表 ， 例 如 : 
discovery.zen.ping.unicast.hosts: ["host1", "host2:port"] 
以 上 配置 可 在 配置 文件 elasticsearch.yml 中 找到 。 


6.JVM 配 置 


通常 很 少 需要 更 改 Java 虚 拟 机 (JVM) 选项 。 唯 一 最 可 能 需要 修改 的 是 heap size。 有 两 种 方式 修改 heap size， 最 简单 的 是 修改 ES_HEAP_SIZE 环 境 变 量 。 服 务 进程 在 启动 的 时 候 会 读 取 这 个 变量 。 


export ES HEAP SIZE-10g 


还 有 就 是 在 配置 文件 /etc/default/elasticsearch 中 加 入 如 下 语句 : 


ES HEAP SIZE-10g 


Elasticsearch 默 认 安装 后 设置 的 heap size 是 1GB。 在 实际 的 生产 环境 中 ，1GB 太 小 了 ， 从 性 能 角度 考虑 ， 需 要 将 这 个 值 改 大 ， 但 不 是 越 大 越 好 ， 官 方 建议 不 要 超过 32CB。 


8.6 Kibana 


Kibana 是 一 个 专门 为 Elasticsearch 服 务 的 开源 分 析 及 可 视 化 平台 。Kibana 提 供 了 Web 界 面 ， 可 以 快速 创建 各 种 仪表 板 (dashboard) 来 搜索 、 查 看 存储 在 Elasticsearch 中 的 数据 。 


8.6.1 让 Kibana 连 接 到 Elasticsearch 


默认 情况 下 ，Kibana 会 连接 运行 在 本 机 上 的 Elasticsearch。 如 需 连 接 其 他 Elasticsearch 实 例 ， 需 修改 /etc/kibana/kibana.yml 里 的 elasticsearch.url， 然 后 重启 服务 。 


# The URL of the Elasticsearch instance to use for all your queries. 
f elasticsearch.url: "http://localhost:9200" 


访问 localhost/status 可 查看 Kibana 的 状态 ， 如 图 8-6 所 示 。 


如 果 使 用 的 是 默认 配置 ， 则 通过 浏览 器 访问 localhost:5601 即 可 见 Kibana Dashboard， 如 图 8-7 所 示 。 


Heap Total Heap Used 


64.63 MB 54.92 MB 2:239, 2,13; 2.79 


Discover 
Visualize 


Dashboard 


Response Time Avg Response Time Max Requests Per Second 


0.00 ms 0.00 ms 0.00 


Timelion 
Dev Tools 
Management 


Status Breakdown 
Status 
plugin:kibana@6.2.2 v Ready 


plugin:elasticsearch@6.2.2 v Ready 


plugin:timelion@6.2.2 v Ready 
plugin:console&6.2.2 v Ready 


plugin:metrics&»6.2.2 v Ready 


Build 16588, Commit SHA 24d8d9d6 


图 8-6 ”查看 Kibana 的 状态 


Add Data to Kibana Data already in Elasticsearch? 


Use these solutions to quickly turn your data Into pre-bullt dashboards and monitoring systems. Set up index patterns 
Discover 


Visualize [mem] 
E 
Dashboard - 
L 
Timelion 
APM Logging Metrics Security analytics 


Dev Tools APM automatically collects In- Ingest logs from popular data Collect metrics from the Centralize security events for 
depth performance metrics and sources and easily visualize in operating system and services interactive Investigation in 
Management errors from inside your preconfigured dashboards. running on your servers. ready-to-go visualizations. 
applications. 


Visualize and Explore Data Manage and Administer the Elastic Stack 


一 一 Dashboard Discover ==» (Console 里 Index Patterns 

- Display and share a Interactively explore your pm Skip cURL and use this JSON Manage the Index patterns 
collection of visualizations data by querying and Interface to work with your that help retrieve your data 
and saved searches. filtering raw documents. data directly. from Elasticsearch. 


E Timelion Visualize Q Saved Objects 


Use an expression language Create visualizations and Import, export, and manage 

to analyze time series data aggregate data stores in your saved searches, 

and visualize the results. your Elasticsearch Indices. visualizations, and 
dashboards. 


Didn't find what you were looking for? 


View full directory of Kibana plugins 


© Collapse 


图 8-7  Kibana Dashboard 


8.6.2 Index Pattern 


第 一 次 访问 Kibana 的 时 候 ， 系 统 会 提示 你 定义 一 个 或 多 个 Index Pattern。 请 注意 ， 如 对 接 的 Elasticsearch 没 有 任何 数据 时 ， 无 法 在 界面 上 创建 Index Pattern。 这 里 我 们 将 一 套 莎 士 比 亚 的 全 部 作品 的 
数据 导入 到 Elasticsearch 中 进行 如 下 的 学 习 [1]。 


数据 导入 成 功 后 ， 就 能 创建 Index Patterns 了 。 管理 Index Pattern 的 位 置 在 Management->Index Patterns F. 


1) 在 Index Pattern 下 输入 shakes*， 这 样 就 会 匹配 到 shakespeare 这 个 索引 ， 如 图 8-8 所 示 。 


Management / Kibana 


Index Patterns Saved Objects Advanced Settings 


Create index pattern 


No default index pattern. Kibana uses index patterns to retrieve data from Elasticsearch indices for things like 
You must select or create visualizations 


one to continue. 


Include system Indices 


Step 1 of 2: Define index pattern 


Index pattern 


shakes*| 


You can use a * as a wildcard in your index pattern. 
You can't use empty spaces or the characters V, /, ?, ", €, », |. > Next step 


v Success! Your index pattern matches 1 index. 


shakespeare 


Rows per page: 10 ^^ 


图 8-8 创建 Index Pattern. (1) 
2) 点 击 下 一 步 ， 进 入 Index Pattern 的 配置 ， 如 图 8-9 所 示 。 


Management / Kibana 


Index Patterns Saved Objects Advanced Settings 


(Warning ) Create index pattern 
No default Index pattern. Klbana uses Index patterns to retrieve data from Elasticsearch indices for things like visualizations. 
You must select or create 


one to continue. 
Step 2 of 2: Configure settings 


You've defined shakes* as your index pattern. Now you can specify some settings before we create It. 


Time Filter field name Refresh 
The indices which match this index pattern don't contain 
any time fields. 


> Show advanced options 


图 8-9 ”创建 Index Pattern. (2) 
3) 点 击 create index pattern 完 成 创建 ， 页 面 显 示 如 图 8-10 所 示 。 
有 了 Index Pattern 后 ， 你 可 以 : 
.在 Discovet 页 搜索 和 浏览 你 的 数据 ; 
: 在 Visualize 页 转换 数据 成 图 表 ; 


在 Dashboard 页 创建 定制 自己 的 仪表 板 。 


关于 Kibana 的 使 用 请 参考 官方 手册 [9]。 


Index Patterns Saved Objects Advanced Settings 


* shakes* 


This page lists every field in the shakes* Index and the field's assoclated core type as recorded by Elasticsearch. While this list allows you to 
view the core type of each field, changing field types must be done using Elasticsearch's Mapping API 9» 


fields (15) scripted Fields (0) source filters (0) 
Q Filter All field types 一 


type 全 searchable € * ^ aggregatable O ^ — excluded € + controls 
string ad Ld rd 
string {v v 
number 
source 
string 
line Id number 
line number string 
line number.keyword string 
play name string 
speaker string 
speech number number 
text entry string 
text entry.keyword string 
type string 
type.keyword string 


(^ 1— 5 ,—*$ 1, 5 a 5— 100—881 1818 0M 


Ld 
v 
xv 
Ld 
bal 
ad 
ad 
Lad 
x 
ad 
Lad 


Scroll to top Page Size[25 d 


图 8-10 ”创建 Index Pattern. (3) 
[1] Loading sample data, https:/ /www.elastic.co/ guide/en/kibana/ 6.2/tutotial-load-dataset.html。 


[2] KibanaJf] P FA, https:/ /www.elastic.co/guide/cn/kibana/cutrent/index.html o 


8.7 部 署 


你 可 能 留意 到 ， 我 们 一 直 没 有 提 到 ELK 各 个 组 件 的 安装 ， 这 是 因为 社区 提供 了 自动 化 部 署 方法 来 部 署 整套 系统 ， 不 需要 手工 一 个 个 地 去 部 署 。 关 于 如 何 自动 化 部 署 可 参见 第 10 章 。 


社区 部 署 时 ， 组 件 在 节点 的 分 布 如 图 8-11 所 示 。 
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Gearman Log 


Gearman Log 
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Server 


Logstash 


Kibana Indexer 


图 8-11 节点 规划 


部 署 完 成 后 ， 需 要 登录 到 各 个 节点 上 去 手动 启动 所 部 署 的 服务 。 


8.8 本章 小 结 


本 章 介绍 了 日 志 分 析 系 统 的 架构 和 使 用 到 的 ELK stack 中 各 个 组 件 的 基本 知识 点 和 简单 的 使 用 操作 。 


第 9 章 ”公共 组 件 详解 


本 章 介绍 OpenStack Cl/CD 系 统 中 使 用 的 三 个 公共 组 件 : Gearman、ZeroMQ 和 ZooKeeper， 它 们 在 系统 中 的 作用 如 下 。 
.Geatman。 用 于 组 件 之 间 的 通信 ， 比 如 : Zuul 通 过 Gearman 向 Jenkins 分 发 任务 ; Nodepool 可 以 通过 Geatman 从 Zuul 和 Jenkins 中 获取 Slave 的 使 用 情况 等 。 
: ZeroMQ。Jenkins 通 过 ZeroMQ 发 布 任务 的 启动 、 完 成 等 事件 ， 供 Nodepool、 日 志 分 析 系 统 读 取 。 


: ZooKeeper。 主 要 用 于 协助 Nodepool 存 储 镜像 制作 信 息 。 


9.1 “任务 分 发 系统 (Gearman) 


9.1.1 Gearman 介 绍 


为 了 扩展 Jenkins 的 性 能 、 实 现 Jenkins 的 HA， 以 及 在 分 布 式 系统 的 各 个 组 件 之 间或 者 组 件 内 部 通信 ， 在 CI/CD 系 统 中 引入 了 Gearman 组 件 。 


Gearman 提 供 了 一 种 通用 的 应 用 程序 框架 ， 将 任务 分 发 到 适当 的 机 器 或 者 进程 当中 。 它 为 应 用 程序 提供 了 并 行 工作 、 负 载 均衡 处 理 的 能 力 ， 以 及 在 不 同 编程 语言 之 间 调 用 的 能 力 。Gearman 能 够 在 很 
多 应 用 程序 中 使 用 ， 比 如 高 可 用 的 Web 站 点 、 数 据 库 事件 复制 分 发 系统 等 ， 换 句 话说 ， 它 就 是 一 个 负责 分 布 式 处 理 通信 的 中 枢 系 统 。 


Gearman 的 优点 包括 [如 下 部 分 。 

| 开源 : Gearman 是 自由 软件 ， 它 遵循 BSD 协 议 ， 可 以 免费 使 用 。Gearman 有 一 个 活跃 的 开源 社区 ， 用 户 很 容易 就 可 以 获得 社区 的 支持 。 

- 支持 多 种 语言 : Gearman 支 持 多 种 编程 语言 接口 。 用 户 可 以 使 用 一 种 语言 编写 Client 程 序 ， 同 时 使 用 另 一 种 语言 编写 Worket 程 序 。 

"灵活: 用 户 不 必 拘 沁 于 固定 的 设计 模式 ， 可 以 选择 任何 模型 (例如 Map/Reduce 模 型 ) ， 从 而 快速 地 将 分 布 式 应 用 整合 在 一 起 。 

` 快速 : Gearman 的 协议 简单 ， 接 口 经 过 了 优化 ， 支 持 线程 化 ， 服 务 端 使 用 C/C++ 实现 ， 从 而 减 小 了 应 用 的 开销 。 

| 可 植 入 : 因为 Gearman 非 常 快速 和 轻 量 ， 从 而 适用 于 各 种 规模 的 应 用 程序 。 它 可 以 很 容易 地 被 引入 到 现 有 的 应 用 程序 中 ， 而 且 开销 很 小 。 
. 无 单 点 故障 : Gearman 不 仅 可 以 用 来 帮助 扩展 系统 ， 同 时 还 可 以 帮助 系统 实现 容错 。 

. 消息 大 小 无 限制 : Gearman 支 持 的 单个 消息 长 达 4GB。 如 果 需 要 支持 更 大 的 消息 ， 也 没有 问题 ，Gearman 支 持 对 消息 进行 分 块 及 组 装 。 


[1] http:/ /gearman.orgo 
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为 了 扩展 Jenkins 的 性 能 、 实 现 Jenkins 的 HA， 以 及 在 分 布 式 系统 的 各 个 组 件 之 间或 者 组 件 内 部 通信 ， 在 CI/CD 系 统 中 引入 了 Gearman 组 件 。 
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多 应 用 程序 中 使 用 ， 比 如 高 可 用 的 Web 站 点 、 数 据 库 事件 复制 分 发 系统 等 ， 换 句 话说 ， 它 就 是 一 个 负责 分 布 式 处 理 通信 的 中 枢 系 统 。 


Gearman 的 优点 包括 [如 下 部 分 。 

. 开源 : Geatman 是 自由 软件 ， 它 遵循 BSD 协 议 ， 可 以 免费 使 用 。Geatman 有 一 个 活跃 的 开源 社区 ， 用 户 很 容易 就 可 以 获得 社区 的 支持 。 

. 支持 多 种 语言 : Gearman 支 持 多 种 编程 语言 接口 。 用 户 可 以 使 用 一 种 语言 编写 Client 程 序 ， 同 时 使 用 另 一 种 语言 编写 Worket 程 序 。 

"灵活: 用 户 不 必 拘 沁 于 固定 的 设计 模式 ， 可 以 选择 任何 模型 (例如 Map/Reduce 模 型 )， 从 而 快速 地 将 分 布 式 应 用 整合 在 一 起 。 

| 快速 : Gearman 的 协议 简单 ， 接 口 经 过 了 优化 ， 支 持 线 程 化 ， 服 务 端 使 用 C/C++ 实现 ， 从 而 减 小 了 应 用 的 开销 。 

. 可 植 入 : 因为 Gearman 非 常 快速 和 轻 量 ， 从 而 适用 于 各 种 规模 的 应 用 程序 。 它 可 以 很 容易 地 被 引入 到 现 有 的 应 用 程序 中 ， 而 且 开销 很 小 。 
. 无 单 点 故障 : Gearman 不 仅 可 以 用 来 帮助 扩展 系统 ， 同 时 还 可 以 帮助 系统 实现 容错 。 

. 消息 大 小 无 限制 : Gearman 支 持 的 单个 消息 长 达 4GB。 如 果 需 要 支持 更 大 的 消息 ， 也 没有 问题 ，Geatrman 支 持 对 消息 进行 分 块 及 组 装 。 


[1] http:/ /gearman.orgo 


9.1.2 Gearman 架 构 和 工作 原理 


Gearman 的 应 用 系统 通常 包括 三 个 部 分 : Client (客户 端 ) 、Worker (工作 端 ) 和 Job Server (任务 服务 器 ) 。 其 架构 如 图 9-1 所 示 。 
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图 9-1 Gearman 应 用 系统 架构 


Gearman 提 供 了 Job Server ( 即 gearmand 程 序 ， 也 可 称 为 Gearman 服 务 器 或 Gearman Server) ， 以 及 Client 和 Worker 的 API。 应 用 程序 可 以 利用 Gearman 的 API 同 Job Server 通 信 ， 而 不 需要 自己 
负责 网 络 通 信 或 者 任务 的 映射 关系 。 在 Gearman 内 部 ，Client 和 Worker 的 API 通 过 TCP 套 接 字 与 Job Server 进 行 通信 。 


Client 的 作用 是 创建 Job (任务 ) ， 并 把 Job 提 交 给 Job Server, Job Server 寻 找 一 个 能 够 运行 这 项 Job 的 合适 的 Worker， 并 把 Job 转 发 到 这 个 Worker 上 来 运行 。Worker 执 行 Client 请 求 的 Job， 并 且 通 
过 Job Server 将 响应 消息 返回 给 Client。 


1.Gearman 的 典型 用 例 
通过 使 用 Gearman， 开 发 者 可 以 在 不 同 语言 编写 的 Client 和 Worker 之 间 进 行 通 信 。Gearman 支 持 的 语言 包括 : C、C#/.NET、Go、Java、Lisp、Nodejs、PHP、Perl、Python、Ruby 等 。 


通过 使 用 Gearman， 开 发 者 可 以 将 Worker 代 码 放 在 更 合适 的 机 器 (或 一 组 机 器 ) 上 执行 ， 从 而 实现 负荷 均衡 。 举 例 来 说 : 假设 用 户 有 一 个 Web 应 用 程序 需要 进行 图 像 格式 转换 ， 但 是 Web 服 务 器 的 负 
荷 比 较 重 ， 用 户 就 可 以 通过 Gearman 将 图 像 发 送 到 专门 的 一 组 机 器 上 进行 格式 转换 ， 这 样 就 不 会 影响 Web 服 务 器 的 性 能 。 


通过 使 用 Gearman， 应 用 程序 可 以 更 好 地 利用 多 核 服务 器 的 性 能 ， 而 且 这 种 扩展 非常 简单 。 假 设 一 台 服 务 器 上 的 CPU 有 16 个 核 ， 用 户 就 可 以 启动 16 个 Worker 程 序 的 实例 ， 每 个 实例 绑 定 一 个 CPU 核 ; 
不 绑 定 的 情况 下 ， 可 以 启动 更 多 的 Worker 实 例 。 


通过 使 用 Gearman， 应 用 系统 可 以 更 简单 地 进行 水 平 扩展 。 比 如 说 ， 用 户 新 购置 了 一 组 服务 器 ， 则 只 需要 在 它们 上 面 安装 和 启动 Worker 程 序 ， 并 连接 到 Jobserver 上 ， 就 可 以 实现 系统 性 能 的 无 颖 扩 
展 。 


2.Gearman 集 群 


对 于 使 用 Gearman 的 系统 来 说 ，Job Server 是 系统 的 中 枢 。 用 户 可 能 担心 Job Server 会 造成 系统 的 单 点 故障 。 为 了 实现 系统 的 高 可 用 性 ， 用 户 可 以 同时 运行 多 个 Job Server， 并 让 Client 和 Worker 连 接 
到 第 一 个 可 用 的 Job Server。 这 样 ， 如 果 一 个 Job Server 无 法 连接 ，Client 和 Worker 会 自动 转移 到 另 一 个 Job Server。 图 9-2 显 示 了 一 个 集群 中 有 两 个 Job Server 时 的 连接 方式 。 
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图 9-2 Gearman 集群 


如 果 用 户 不 希望 运行 太 多 Job server， 那 么 运行 2 ~ 3 个 即 可 实现 高 可 靠 性 。Job server 可 以 一 次 轻松 地 处 理 数 百 个 Client 和 Worker 的 连接 。 在 这 种 架构 下 ， 用 户 可 以 根据 需要 来 设计 自己 的 系统 ， 扩 展 
client 和 Worker， 在 容量 允许 的 情况 下 ， 将 工作 负载 分 配 到 任意 数量 的 机 器 上 。 


9.1.3 xx 


使 用 Gearman 服 务 ， 首 先 要 安装 Gearman Job Server; 为 了 查看 服务 的 状态 ， 通 常 还 要 安装 Gearman 的 管理 工具 ; 对 于 开发 人 员 来 说 ， 还 需要 安装 与 开发 语言 对 应 的 库 ， 即 AP|。 
1.Gearman Job Server 


在 Ubuntu 操作 系统 上 安装 : 


sudo apt-get install gearman-job-server 
sudo service gearman-job-server start 


除了 包 安 装 的 方式 外 ， 用 户 也 可 以 从 http://gearman.org/download/ 网 站 下 载 源码 进行 安装 。 

Gearman 服 务 使 用 的 端口 号 默认 为 4730。 用 户 也 可 以 在 启动 服务 的 时 候 使 用 -p 或 --port 选 项 来 指定 端口 : 

sudo gearmand --daemon --port 5000 

用 户 还 可 以 将 Gearmand 所 需 的 参数 写 入 /etc/gearmand.conf， 格 式 与 命令 行 参 数 相 同 ， 以 避免 每 次 启动 服务 时 在 命令 行 里 输入 参数 。 
在 OpenStack CIMCD 系 统 中 ， 一 些 组 件 内 置 了 Gearman Job Server， 例 如 Zuul、 日 志 分 析 系 统 等 ， 不 需要 单独 安装 Gearman Job Server, 
2.Gearman 管 理工 具 

用 户 可 以 安装 Gearman 管 理工 具 来 查询 Gearman 的 状态 。Gearman 管 理工 具 与 Gearman Job Server 可 以 安装 在 不 同 的 机 器 上 。 


在 Ubuntu 操作 系统 上 安装 : 


sudo apt-get install gearman-tools 


Gearman 管 理工 具 的 使 用 方法 参见 代码 清单 9-1。 


代码 清单 9-1 Gearman 管 理工 具 使 用 方法 


$ gearadmin --help 


Options: 
--help Options related to the program. 
-h [ --host ] arg (-localhost) Connect to the host 
-p [ --port ] arg (24730) Port number or service to use for con- 
nection 
--server-version Fetch the version number for the server. 
--server-verbose Fetch the verbose setting for the server. 
--create-function arg Create the function from the server. 
--drop-function arg Drop the function from the server. 
--getpid Get Process ID for the server. 
--status Status for the server. 
--workers Workers for the server. 
--shutdown Shutdown server. 


Gearman 状 态 的 查询 方法 参见 代码 清单 9-2。 


代码 清单 9-2 使 用 Gearman 管 理工 具 查 询 Geaman 的 状态 


$ gearadmin --status 
SayHello 0 0 1 


该 状态 信息 中 ， 第 一 项 为 Job 的 名 称 ， 后 面 三 个 数字 分 别 代表 : 等 待 运行 的 Job 个 数 、 正 在 运行 的 Job 个 数 、 能 处 理 该 Job 的 Worker 的 个 数 。 
Worker 状 态 的 查询 方法 参见 代码 清单 9-3。 


代码 清单 9-3 ”使 用 Gearman 管 理工 具 查询 Worker 的 状态 


$ gearadmin --workers 
33 127.0.0.1 python-worker : SayHello 
34 ::3438:3333:3000:0$4294967295 - : 


Worker 状 态 信息 中 ， 包 括 了 Worker 的 地 址 、1D 及 其 注册 的 Job 名 。 同 一 台 主 机 可 以 注册 多 个 Worker， 同 一 个 Worker 1D 可 以 注册 多 个 Job。 
3.Gearman API 
Gearman 文 持 多 种 编程 语言 ， 用 户 可 以 选择 自己 熟悉 的 语言 编写 Worker 和 Client 程 序 。 这 里 以 Python 语言 为 例 进 行 说 明 。 


首先 安装 Gearman 的 Python 库 : 


sudo pip install gearman 


编写 一 个 Worker 程 序 worker.py。Worker 程 序 启动 后 ， 就 会 一 直 等 待 Client 的 请 求 ; 当 它 收 到 请 求 时 ， 会 返回 一 串 字 符 ， 内 容 为 “Hello” 以 及 Client 输 入 的 信息 。 其 内 容 参见 代码 清单 9-4。 


代码 清单 9-4 worker.py 


import gearman 


gm worker = gearman.GearmanWorker (['localhost:4730']) 


def task sayhello(gearman worker, gearman job): 
print('Hello ' + gearman job.data) 
return 'Hello ' + gearman job.data 


gm worker.set client id('python-worker') 


gm worker.register task('SayHello', task sayhello) 


gm worker.work() 


编写 一 个 Client 程 序 client.py， 它 向 Job Server 发 送 一 串 字 符 ， 并 显示 从 Job Server 返 回 的 字符 。 其 内 容 参 见 代 码 清单 9-5。 


代码 清单 9-5 client.py 


import gearman 


def check request status(job request): 
if job request.complete: 
print('Job $s finished! Result: $s - $s' $ 
(job request.job.unique, job request.state, job request.result)) 
elif job request.timed out: 
print('Job $s timed out!' $ job request.unique) 
elif job request.state == JOB UNKNOWN: 
print('Job $s connection failed!' $ job request.unique) 


gm client = gearman.GearmanClient (['localhost:4730']) 


my job request = gm client.submit job('SayHello', 'Tom') 
check request status (my job request) 


先 在 一 个 命令 行 窗口 里 运行 Worker 端 程序 ， 然 后 启动 另 一 个 命令 行 窗口 运行 Client 端 程序 。Client 端 的 运行 结果 如 代码 清单 9-6 所 示 。 


代码 清单 9-6 client.py 运 行 结果 


$ python client.py 
Job 16a4ce54997de4354490ed69cbe8a8cd finished! Result: COMPLETE - Hello Tom 


Worker 端 的 运行 结果 如 代码 清单 9-7 所 示 。 


代码 清单 9-7 worker.py 运 行 结 


$ python worker.py 
Hello Tom 


在 Worker 端 程序 运行 前 后 ， 用 户 可 以 使 用 Gearman 管 理工 具 查 询 Gearman 及 其 Worker 的 状态 变化 。 从 示例 代码 中 可 以 看 出 ，GearmanWorker 和 GearmancClient 实 例 初 始 化 时 指定 的 Job Server 信 息 
为 列表 形式 ， 开 发 者 可 以 在 代码 中 指定 多 个 Job Server 的 信息 ， 即 同时 连接 多 个 服务 器 。 例 如 : 


gm worker = gearman.GearmanWorker(['serverl', 'server2:5000']) 


这 里 ，server1 和 server2 为 Job Server 的 域名 ， 也 可 以 填写 它们 的 IP 地 址 。 其 中 ，server1 的 服务 端口 为 默认 值 4730，server2 的 端口 为 自 定义 的 端口 5000。 


9.1.4 利用 Gearman 实 现 Jenkins 的 HA 


f£OpenStack CIMCD 系 统 中 ，Jenkins Master 本 身 不 具有 HA 的 能 力 ， 随 着 系统 负荷 的 不 断 增加 ，Jenkins Master 会 成 为 系统 的 瓶颈 。 在 引入 Gearman 之 前 ， 系 统 的 架构 如 图 9-3 所 示 [1]。 
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图 9-3 引入 Gearman 之 前 的 系统 架构 


OpenStack CI/CD 系 统 引 入 Gearman 之 后 ， 在 Jenkins Master 上 安装 Gearman 插 件 ， 使 其 向 Gearman Job Server 注 册 Worker，Worker 信 息 中 包含 了 Jenkins Slave 和 Job 的 信息 ; Zuul 不 再 与 
Jenkins 直 接 交 互 ， 而 是 提交 执行 任务 的 请 求 给 Gearman Job Server， 由 Gearman Job Server 将 任务 分 发 给 Jenkins 注 册 的 Worker。 系 统 中 同时 部 署 多 个 Jenkins Master， 不 同 的 Jenkins Master 
Gearman Job Server 中 注册 的 Worker 可 以 提供 相同 任务 名 ，Gearman Job Server 在 分 发 任务 时 可 以 选择 合适 的 Worker 来 处 理 任务 ， 从 而 实现 了 Jenkins Master 的 HA 和 负 葵 分 担 。 引 入 Gearman 之 后 的 
系统 架构 如 图 9-4 所 示 。 
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图 9-4 引入 Gearman 之 后 的 系统 架构 
有 关 Jenkins 的 Gearman 插 件 的 安装 和 使 用 ， 请 参考 本 书 的 第 4 章 。 


[1] https://docs.openstack.org/infra/publications/gearman-plugin/ o 


9.2 消息 队列 (ZeroMQ) 


92.1 ZeroMQ 介 绍 


ZeroMQ (也 称 为 ¥MQ、0MQ 或 zmq) 是 一 个 为 可 伸缩 的 、 分 布 式 或 并 发 应 用 程序 设计 的 高 性 能 异步 消息 库 。 它 是 由 iMatix 公 司 和 大 量 贡献 者 组 成 的 社区 共同 开发 的 开源 软件 ， 以 LGPLv3 许 可 证 发 
布 。 值 得 一 提 的 是 ，iM atix 公 司 也 参与 了 知名 的 消息 队列 协议 AMQP (Advanced Message Queuing Protocol) 的 早期 设计 ， 后 来 为 了 专注 于 ZeroM Q 而 宣布 不 再 支持 AMQP。ZeroMQ 对 复杂 繁琐 的 网 
络 通信 的 底层 细节 进行 了 封装 ， 使 开发 者 可 以 更 加 专注 于 上 层 应 用 。 它 为 开发 者 提供 了 多 种 套 接 字 ， 用 来 传输 用 户 的 原子 消息 。ZeroMQ 的 套 接 字 支持 多 对 多 的 连接 ; 可 以 实现 进程 内 、 进 程 间 、TCP 和 多 
播 等 多 种 通信 方式 ;支持 多 种 工作 模式 ， 如 “请 求 -应 答 ” “发布 -订阅 ” “任务 分 发 ”等 。 使 用 者 可 以 把 它 当 作 一 个 嵌入 式 网 络 消息 开发 库 ， 也 可 以 用 它 来 构建 一 个 并 发 框架 。 


ZeroMQ 为 用 户 提供 了 一 个 消息 队列 ， 但 与 很 多 消息 中 间 件 不 同 的 是 ，ZeroMQ 的 运行 不 需要 专门 的 消息 代理 (message broker) 。 它 的 名 字 中 的 zero 代 表 了 零 代 理 、 ( 尽 可 能 ) 零 延 迟 ， 也 代表 了 一 
些 其 他 目标 : 零 管 理 、 零 开销 、 零 浪费 。 与 很 多 其 他 同类 消息 软件 相 比 ，ZeroM Q 的 最 大 特点 是 使 用 非常 简单 ， 而 且 性 能 很 高 。 


ZeroMQ 可 以 在 大 多 数 操作 系统 上 运行 ， 并 支持 多 种 开发 语言 ， 包 括 : C、C++、C#、Go、Java、JavaScript、Perl|、PHP、Python、Ruby 等 。 开 发 者 可 以 同时 使 用 多 种 编程 语言 ， 组 成 异 构 系统 ， 
比如 : 使 用 C 语 言 开 发 的 软件 通过 ZeroMQ 发 布 消息 ， 并 使 用 Python 语言 开发 的 软件 通过 ZeroM Q 接 收 消息 。 


9.2 ”消息 队列 (ZeroMQ) 


92.1 ZeroMQ 介 绍 


ZeroMQ (也 称 为 ¥MQ、0MQ 或 zmq) 是 一 个 为 可 伸缩 的 、 分 布 式 或 并 发 应 用 程序 设计 的 高 性 能 异步 消息 库 。 它 是 由 iMatix 公 司 和 大 量 贡献 者 组 成 的 社区 共同 开发 的 开源 软件 ， 以 LGPLv3 许 可 证 发 
布 。 值 得 一 提 的 是 ，iM atix 公 司 也 参与 了 知名 的 消息 队列 协议 AMQP (Advanced Message Queuing Protocol) 的 早期 设计 ， 后 来 为 了 专注 于 ZeroM Q 而 宣布 不 再 支持 AMQP。ZeroMQ 对 复杂 繁琐 的 网 
络 通信 的 底层 细节 进行 了 封装 ， 使 开发 者 可 以 更 加 专注 于 上 层 应 用 。 它 为 开发 者 提供 了 多 种 套 接 字 ， 用 来 传输 用 户 的 原子 消息 。ZeroMQ 的 套 接 字 支持 多 对 多 的 连接 ;可 以 实现 进程 内 、 进 程 间 、TCP 和 多 
播 等 多 种 通信 方式 ;支持 多 种 工作 模式 ， 如 “请 求 -应 答 ”“ 发 布 -订阅 ” “任务 分 发 ”等 。 使 用 者 可 以 把 它 当 作 一 个 嵌入 式 网 络 消息 开发 库 ， 也 可 以 用 它 来 构建 一 个 并 发 框架 。 


ZeroMQ 为 用 户 提供 了 一 个 消息 队列 ， 但 与 很 多 消息 中 间 件 不 同 的 是 ，ZeroMQ 的 运行 不 需要 专门 的 消息 代理 (message broker) 。 它 的 名 字 中 的 zero 代 表 了 零 代 理 、 ( 尽 可 能 ) 零 延 迟 ， 也 代表 了 一 
些 其 他 目标 : 零 管 理 、 零 开销 、 零 浪费 。 与 很 多 其 他 同类 消息 软件 相 比 ，ZeroM Q 的 最 大 特点 是 使 用 非常 简单 ， 而 且 性 能 很 高 。 


ZeroMQ 可 以 在 大 多 数 操作 系统 上 运行 ， 并 支持 多 种 开发 语言 ， 包 括 : C、C++、C#、Go、Java、Javascript、Perl|、PHP、Python、Ruby 等 。 开 发 者 可 以 同时 使 用 多 种 编程 语言 ， 组 成 异 构 系统 ， 
比如 : 使 用 C 语 言 开 发 的 软件 通过 ZeroMQ 发 布 消息 ， 并 使 用 Python 语言 开发 的 软件 通过 ZeroM Q 接 收 消息 。 


9222 ”ZeroMQ 的 特点 


ZeroMQ 有 如 下 特点 。 

. 异步 : ZeroMQ 在 后 台 线 程 中 异步 处 理 I/O。 线 程 中 使 用 无 锁 数据 结构 ， 并 发 的 ZeroMQ 应 用 程序 不 需要 使 用 锁 、 信 号 量 或 者 其 他 的 等 待 状态 指示 。 
. 自动 重 连 : 应 用 程序 不 需要 关心 启动 的 顺序 ， 可 以 动态 加 入 或 者 离开 ZeroMQ 网 络 ，ZeroMQ 会 自动 重 连 。 

. 智能 排队 : ZeroMQ 会 在 有 需要 时 智能 地 自动 将 消息 放 进 队列 。 

- BAË: ZeroMQ 有 阅 值 ( 称 为 “高 水 位 ”) 机 制 。 当 队列 满 时 ，ZeroMQ 自 动 阻塞 发 送 者 ， 或 者 丢弃 消息 ， 这 些 行为 取决 于 使 用 的 消息 模式 。 
. 多 种 通信 方式 : ZeroMQ 支 持 多 种 通信 方式 : TCP、 多 播 、 进 程 内 、 进 程 间 ， 无 须 修改 代码 以 使 用 不 同 的 方式 。 

. 缓慢 /受阻 节点 处 理 : ZeroMQ 会 安全 地 处 理 速度 较 慢 或 受阻 塞 的 节点 ， 会 根据 消息 模式 使 用 不 同 的 策略 。 

.多 种 消息 路 由 模式 : ZeroMQ 提 供 了 多 种 消息 路 由 的 模式 ， 比 如 : 请求- 应答、 发布- 订阅。 使 用 者 可 以 根据 自己 的 网 络 架 构 、 拓 扑 来 选择 不 同 的 模式 。 
. 增加 代理 : 用 户 可 以 创建 代理 ， 来 缓存 、 转 发 或 者 捕获 消息 。 代 理 可 以 降低 网 络 中 互联 的 复杂 度 。 

` 消息 完整 : ZeroMQ 会 发 送 完整 的 消息 ， 使 用 简单 的 帧 格式 来 传递 。 接 收 端 收 到 的 消息 与 发 送 端 发 送 的 消息 完全 一 致 。 

` 消息 透明 : ZeroMQ 对 消息 的 格式 没有 要 求 ， 消 息 长 度 可 以 从 0 字 节 到 千 兆 字 节 。 

- 智能 容错 : ZeroMQ 会 通过 自动 重 试 以 智能 地 处 理 网 络 错误 。 


.降低 能 耗 : ZeroMQ 占 用 CPU 开销 很 小 ， 这 意味 着 使 用 者 可 以 节约 能 耗 ， 降 低 碳 排放 。 


923 ZeroMQ 的 工作 模式 


ZeroMQ 提 供 了 多 种 套 接 字 用 于 网 络 连 接 。 与 普通 的 TCP 连 接 相 比 ，ZeroM Q 的 连接 有 如 下 特点 。 
. 使 用 多 种 通信 方式 : inproc (进程 内 ) ~ ipe (进程 间 ) ~ tcp pem (广播 ) 、epgm 等 。 
:一 个 套 接 字 可 以 有 多 个 输出 和 输入 连接 。 
- 没有 提供 类 似 zmq_accept0 的 函数 ， 因 为 当 套 接 字 绑 定 到 端点 时 它 就 自动 开始 接受 连接 。 
- 网 络 连 接 在 后 台 自 动 建立 。 当 连接 被 破坏 后 ZeroMQ 会 自动 重 连 (在 对 端 恢 复 可 达 的 情况 下 ) o 
` 应 用 程序 的 代码 不 能 直接 访问 这 些 连接 ， 因 为 它们 被 封装 在 ZeroMQ 的 套 接 字 底层 。 
ZeroMQ 的 套 接 字 提 供 了 多 种 消息 模式 ， 核 心 的 消息 模式 包括 : 
. 请 求 -应 答 (Requestreply) 模式 : 将 一 组 服务 端 和 一 组 客户 端 相连 ， 用 于 远程 过 程 调用 或 者 任务 分 发 。 
.发布 -订阅 (Pub-sub) 模式 : 将 一 组 发 布 者 和 一 组 订阅 者 相连 ， 用 于 数据 分 发 。 
` 管道 (Pipeline) 模式 : 使 用 启 入 或 启 出 的 形式 连接 多 个 节点 ， 可 以 有 多 个 步 又 或 循环 ， 用 于 并 行 任务 分 发 和 收集 。 
: 排他 对 (Exclusive pair) 模式 : 将 两 个 套 接 字 一 对 一 的 连接 起 来 ， 该 连接 是 排 它 的 。 这 种 模式 用 于 将 一 个 进程 内 的 两 个 线程 连接 起 来 。 
以 下 是 可 用 于 连接 - 绑 定 对 (connect-bind pair) 的 合法 的 套 接 字 组 合 (任何 一 端 都 可 以 绑 定 ) : 
- PUB 和 SUB 
- REQ 和 REP 
- REQ 和 ROUTER (注意 ，REQ 会 插入 额外 的 空 帧 ) 
: DEALER 和 REP (注意 ，REP 会 假定 有 一 个 空 帧 ) 
- DEALER 和 ROUTER 
. DEALER 和 DEALER 
- ROUTER 和 ROUTER 
. PUSH 和 PULL 
. PAIR 和 PAIR 
其 中 ，PUB 套 接 字 和 SUB 套 接 字 用 于 “发 布 - 订 阅 ” 模 式 ; REQ 套 接 字 和 REP 套 接 字 用 于 “请 求 -应 答 ” 模 式 ; PUSH 套 接 字 和 PULL 套 接 字 用 于 单 向 消息 推送 ; PAIR 用 于 进程 内 通信 。 


对 于 一 些 复杂 的 场景 ， 比 如 说 我 们 需要 让 多 个 Client (使 用 REQ 套 接 字 ) 和 多 个 Server (使 用 REP 套 接 字 ) 进行 通信 ， 如 果 让 它们 之 间 直 接连 接 ， 一 旦 Server 数 目 发 生 了 变化 ， 则 所 有 的 Client 都 需要 进 
行 修 改 。ZeroMQ 使 用 DEALER 套 接 字 和 ROUTER 套 接 字 解决 这 种 问题 : REQ 套 接 字 和 ROUTER 套 接 字 通信 ，DEALER 套 接 字 和 REP 套 接 字 通信 ，ROUTER 和 DEALER 之 间 则 需要 进行 消息 转发 。 


本 节 对 于 ZeroMQ 只 是 进行 一 般 性 的 介绍 ， 以 及 提供 一 些 简单 的 例子 。 如 果 读 者 想 深入 了 解 ZeroMQ 的 知识 ， 学 习 更 多 示例 代码 ， 而 不 限于 其 在 OpenStack CIMCD 中 的 应 用 ， 则 请 参阅 ZeroMQ 指 导 文 
gulll, 


[1] http:/ /zguide.zeromq.otg. 


9.24 安装 


如 前 所 述 ，ZeroM Q 不 需要 运行 单独 的 消息 代理 ， 也 不 需要 自己 的 服务 。 因 此 ， 安 装 ZeroM Q 只 需要 安装 开发 运行 所 需 的 库 即 可 。 


如 果 使 用 Python 语言 开发 ZeroMQ 应 用 程序 ， 则 需要 安装 pyzmq 包 : 


sudo pip install pyzmq 


9.2.5 ”应 用 示例 


本 节 中 的 示例 程序 均 使 用 Python 语言 编写 。 


1. 请 求 -应 答 模式 


请 求 -应 答 模 式 


图 9-5 


本 节 介绍 一 个 “请 求 -应 答 ” 模 式 的 例子 ， 包 含 客户 端 (REQ) 和 服务 器 端 (REP) 两 个 程序 。 服 务 端 根据 客户 端 请 求 消息 的 内 容 ， 应 答 不 同 的 响应 消息 。 其 架构 如 图 9-5 所 示 。 


服务 端 程 序 rep-server.py 的 内 容 参 见 代 码 清单 9-8。 


代码 清单 9-8 rep-server.py 


import time 
import zmq 


context = zmq.Context () 
Socket = context.socket (zmq.REP) 
Socket.bind("tcp://*:5678") 


data — ("name": "Tom", "age": 25] 

while True: 
message = socket.recv() 
print("Received request: $s" $ message) 
time.sleep (1) 


Socket.send(str(data.get (message, " 


I don't understand"))) 


客户 端 程序 req-client.py 的 内 容 参见 代码 清单 9-9。 


代码 清单 9-9 req-client.py 


import zmq 


context = zmq.Context () 
Socket = context.socket (zmq.REQ) 
Socket.connect ("tcp: //localhost:5678") 


for request in ["name", "age", "address"]: 


print (">>> Sending request: $s http://www.hzcourse.com/resource/readBook?path-/openresources/teach ebook/uncompressed/17 


socket .send (request) 
message = socket.recv() 
print ("<<< Received reply: $s 


[ $s ]" $ 


(request, message)) 


先 在 一 个 命令 行 窗口 里 运行 服务 端 程序 ， 然 后 启动 另 一 个 命令 行 窗口 运行 客户 端 程序 。 客 户 端的 运行 结果 参见 代码 清单 9-10。 


代码 清单 9-10 ”req-client.py 运 行 结果 


933/OEBPS/Text/..." $ 


request) 


$ python req-client 


«PY 
Connecting to server http://www.hzcourse.com/resource/readBook?path-/openresources/teach ebook/uncompressed/17933/0EBPS/Text/... 


>>> 


Sending request: 


<<< 
>>> 
<<< 
>>> 
<<< 


Received reply: name [ Tom ] 
Sending request: 
Received reply: 
Sending request: 
Received reply: address [ 


age [ 25 ] 


I don't understand ] 


服务 端的 运行 参见 代码 清单 9-11。 


代码 清单 9-11 rep-server.py 运 行 结果 


address http://www.hzcourse.com/resource/readBook?path-/openresources/teach ebook/uncompressed/17933/0E 


name http://www.hzcourse.com/resource/readBook?path-/openresources/teach ebook/uncompressed/17933/OEBPS 


/Text/... 


age http://www.hzcourse.com/resource/readBook?path-/openresources/teach ebook/uncompressed/17933/OEBPS/Text/... 


BPS/Text/... 


$ python rep-server.py 
Received request: name 
Received request: age 
Received request: address 


人 小。 


2. 发 布 -订阅 模式 


本 节 将 介绍 一 个 “发 布 -订阅 ”模式 的 例子 ， 包 含 客户 端 (SUB) 和 服务 器 端 (PUB) 两 个 程序 。 服 务 端 循环 发 送 1 ~ 10 这 十 个 数字 ， 客 户 端 接收 一 个 完整 的 循环 ， 并 打印 累加 结果 。 其 架构 如 图 9-6 所 


bind 


updates 


updates updates updates 


connect connect connect 


图 9-6 ”发 布 -订阅 模式 
服务 端 程序 publisher.py 的 内 容 参 见 代 码 清单 9-12。 


代码 清单 9-12 publisher.py 


import time 
import zmq 


context = zmq.Context () 
Socket = context.socket (zmq.PUB 
Socket.bind("tcp://*:5678") 


— 


while True: 

Socket.send("start") 
for num in range(10): 
Socket.send(str (num + 1)) 
Socket.send ("end") 
time.sleep (1) 


客户 端 程序 subscriber.py 的 内 容 参 见 代 码 清单 9-13。 


代码 清单 9-13 subscriber.py 


import zmq 


context = zmq.Context () 
Socket = context.socket (zmq.SUB) 


Socket.connect ("tcp: //localhost:5678") 
Socket.setsockopt (zmq.SUBSCRIBE, "") 


Start 
total 


False 
0 


while True: 
data = socket.recv() 


if not start and data == "start": 
Start = True 

elif data == "end": 
print "End. Total = ", total 
break 

elif data.isdigit(): 


total += int (data) 


先 在 一 个 命令 行 窗口 里 运行 服务 端 程序 ， 然 后 启动 另 一 个 命令 行 窗口 运行 客户 端 程序 。 服 务 端 没有 打印 输出 ， 客 户 端的 运行 结果 参见 代码 清单 9-14。 


代码 清单 9-14 subscriber.py 运 行 结 果 


$ python subscriber.py 
End. Total = 55 


使 用 SUB 套 接 字 时 ， 还 可 以 在 调用 socket.setsockopt( 接 口 时 设置 过 滤器 ， 从 服务 端 发 送 的 众多 消息 中 过 滤 出 自己 感 兴趣 的 内 容 ， 而 不 是 全 部 接收 ， 本 例 中 没有 设置 过 滤 规 则 。 


9.2.6 ZeroMQft£OpenStack CIMCD 系 统 中 的 作用 

在 OpenStack CI/CD 系 统 中 ，ZeroMQ 主 要 用 于 Jenkins 和 Nodepool、 日 志 分 析 系 统 之 间 通 信 。Jenkins 通 过 ZeroMQ 插 件 (ZMQ Event Publisher) 使 用 “发 布 -订阅 ”模式 将 任务 的 启动 、 完 成 等 事 
件 发 布 出 去 ， 供 Nodepool、 日 志 分 析 系 统 等 组 件 消费 。 

关于 Jenkins 插 件 请 参考 第 4 章 。 


ZeroMQ 在 Nodepool 和 日 志 分 析 系 统 中 的 使 用 请 参考 第 6 章 和 第 8 章 。 


9.3 “分 布 式 协 调 服务 (ZooKeeper) 
9.3.1 ZooKeeper 介 绍 

一 个 分 布 式 系统 ， 通 常 需要 设计 和 开发 一 些 协调 服务 ， 如 果 由 应 用 设计 和 实现 这 些 服务 ， 需 要 执行 额外 的 工作 以 解决 竞争 和 死 锁 问题 。ZooKeeper 的 目的 就 是 为 分 布 式 应 用 解决 这 些 问题 ， 提 供 开 箱 即 
用 的 、 可 靠 的 、 可 扩展 的 、 高 性 能 的 协调 服务 。 


ZooKeeper 是 一 个 面向 分 布 式 应 用 系统 的 开源 协调 服务 ，Google Chubby 的 一 个 开源 实现 ，Hadoop 的 子 项 目 。 它 提供 了 一 套 简单 的 服务 原 语 ， 分 布 式 应 用 基于 它 可 以 实现 同步 、 配 置 管 理 、 群 组 和 名 
字 服 务 。 它 运行 在 Java 虚 拟 机 上 ， 提 供 Java 和 C 的 接口 。ZooKeeper 设 计 为 易于 编程 ， 为 此 它 使 用 一 种 类 似 文件 系统 目录 树 风 格 的 数据 模型 。 


ZooKeeper 是 实现 复杂 同步 协调 服务 的 基础 ， 它 提供 如 下 保证 。 

* 顺序 性 : 客户 端的 更 新 请 求 都 会 根据 它 发 出 的 顺序 被 顺序 地 处 理 。 
原子 性 : 一 个 更 新 操作 要 么 成 功 要 么 失败 ， 没 有 其 他 可 能 的 结果 。 
一致 性 : 客户 端 不 论 连接 到 哪个 服务 器 ， 展 示 给 它 者 是 同一 个 视图 。 


. 可 靠 性 : 一 旦 一 个 更 新 被 应 用 就 被 持久 化 了 ， 除 非 另 一 个 客户 端的 更 新 请 求 修 改 了 当前 值 。 


` 实时 性 : 对 于 每 个 客户 端 它 的 系统 视图 都 是 最 新 的 。 


9.3 “分 布 式 协 调 服务 (ZooKeeper) 
9.3.1 ZooKeeper 介 绍 

一 个 分 布 式 系统 ， 通 常 需要 设计 和 开发 一 些 协调 服务 ， 如 果 由 应 用 设计 和 实现 这 些 服务 ， 需 要 执行 额外 的 工作 以 解决 竞争 和 和 死 锁 问题 。ZooKeeper 的 目的 就 是 为 分 布 式 应 用 解决 这 些 问题 ， 提 供 开 箱 即 
用 的 、 可 靠 的 、 可 扩展 的 、 高 性 能 的 协调 服务 。 


ZooKeeper 是 一 个 面向 分 布 式 应 用 系统 的 开源 协调 服务 ，Google Chubby 的 一 个 开源 实现 ，Hadoop 的 子 项 目 。 它 提供 了 一 套 简 单 的 服务 原 语 ， 分 布 式 应 用 基于 它 可 以 实现 同步 、 配 置 管理 、 群 组 和 名 
字 服 务 。 它 运行 在 Java 虚 拟 机 上 ， 提 供 Java 和 C 的 接口 。ZooKeeper 设 计 为 易于 编程 ， 为 此 它 使 用 一 种 类 似 文件 系统 目录 树 风 格 的 数据 模型 。 


ZooKeeper 是 实现 复杂 同步 协调 服务 的 基础 ， 它 提供 如 下 保证 。 

* 顺序 性 : 客户 端的 更 新 请 求 都 会 根据 它 发 出 的 顺序 被 顺序 地 处 理 。 
: 原子 性 : 一 个 更 新 操作 要 么 成 功 要 么 失败 ， 没 有 其 他 可 能 的 结果 。 
` 一致 性 : 客户 端 不 论 连接 到 哪个 服务 器 ， 展 示 给 它 都 是 同一 个 视图 。 


. 可 人 靠 性 : 一 旦 一 个 更 新 被 应 用 就 被 持久 化 了 ， 除 非 另 一 个 客户 端的 更 新 请 求 修改 了 当前 值 。 


` 实时 性 : 对 于 每 个 客户 端 它 的 系统 视图 都 是 最 新 的 。 


9.3.2 ”ZooKeeper 架 构 和 工作 原理 


ZooKeeper 本 身 也 是 一 个 分 布 式 应 用 程序 。ZooKeeper 遵 循 一 个 简单 的 “客户 端 -服务 器 ”模型 ， 其 中 客户 端 是 使 用 服务 的 节点 ， 而 服务 器 是 提供 服务 的 节点 。ZooKeeper 服 务 器 的 集合 形成 了 一 个 
ZooKeeper 集 合体 (ensemble) 。ZooKeeper 服 务 架 构 逻 辑 图 如 图 9-7 所 示 。 


ZooKeeper Service 


Follower Leader] | Follower | | Observer 


Follower 


Client 


通常 ZooKeeper 由 2n+1 台 服务 器 组 成 ， 每 个 服务 器 都 知道 彼此 的 存在 。 每 个 服务 器 都 维护 一 个 内 存 状 态 镜 像 以 及 持久 化 存储 的 事务 日 志和 快照 。 对 于 2n+1 台 服务 器 ， 只 要 有 n+1 台 (大 多 数 ) 服务 器 
可 用 ， 整 个 系统 就 保持 可 用 。 


图 9-7 ZooKeepet 服 务 架构 逻辑 图 


在 任何 给 定 的 时 间 内 ， 一 个 ZooKeeper 客 户 端 只 连接 到 一 个 ZooKeeper 服 务 器 。 每 个 ZooKeeper 服 务 器 都 可 以 同时 处 理 大 量 客户 端 连接 。 每 个 客户 端 定期 发 送 ping 到 它 所 连接 的 ZooKeeper 服 务 器 ， 
让 服务 器 知道 它 处 于 活跃 和 连接 状态 。 被 ping 的 ZooKeeper 服 务 器 通过 ping Ack 进 行 响应 ， 表 示 服 务 器 也 处 于 活跃 状态 。 如 果 客 户 端 在 指定 时 间 内 没有 收 到 服务 器 的 确认 响应 ， 那 么 客户 端 会 连接 到 集合 
中 的 另 一 台 服 务 器 ， 而 且 客 户 端 会 话 会 被 透明 地 转移 到 新 的 ZooKeeper 服 务 器 。 


1. 工 作 原 理 
ZooKeeper 服 务 器 分 为 如 下 角色 。 

: 领导 者 (Leader) : 负责 进行 投票 的 发 起 和 决议 ， 并 最 终 更 新 系统 状态 。 

: 跟随 者 (Follower) : 用 于 接收 客户 端 请 求 并 返回 结果 给 客户 端 ， 参 与 领导 者 发 起 的 投票 。 

- 观察 者 (Observer) : 可 以 接收 客户 端 连 接 ， 将 写 请 求 转发 给 领导 者 。 它 不 参与 投票 过 程 ， 只 是 同步 领导 者 的 状态 。 它 的 目的 是 为 了 扩展 系统 ， 提 高 读 取 速度 。 
. 学 习 者 (Leamer) : 和 领导 者 进行 状态 同步 的 服务 器 统称 学 习 者 ， 上 述 跟随 者 和 观察 者 都 是 学 习 者 。 


系统 启动 时 ， 集 群 中 的 服务 器 会 选举 出 一 台 服 务 器 作为 领导 者 ， 其 他 的 就 作为 跟随 者 (这 里 先 不 考虑 观察 者 角色 ) 。 接 着 由 跟随 者 来 响应 客户 端的 请 求 ， 对 于 不 改变 系统 一 致 性 状态 的 读 操作 ， 由 跟随 
者 直接 给 客户 端 返回 存放 在 本 地 内 人 存 数 据 库 中 的 数据 ; 对 于 会 改变 系统 状态 的 更 新 操作 ， 则 交 由 领导 者 进行 提议 和 收集 投票 结果 ， 票 数 超过 半数 则 表示 通过 ， 跟 随 者 返回 结果 给 客户 端 。 


ZooKeeper 的 核心 是 原子 广播 ， 这 个 机 制 保证 了 各 个 服务 器 之 间 的 同步 。 实 现 这 个 机 制 的 协议 叫 作 Zab 协 议 。Zab 协 议 有 两 种 模式 ， 它 们 分 别 是 恢复 模式 和 广播 模式 。 当 服务 启动 、 领 导 者 骨 溃 或 者 领 
导 者 失去 了 大 部 分 的 跟随 者 支持 时 ，Zab 就 进入 了 恢复 模式 。 恢 复 模式 需要 重新 选举 出 一 个 新 的 领导 者 ， 当 领导 者 被 选举 出 来 ， 且 大 多 数 服务 器 完成 了 和 领导 者 的 状态 同步 以 后 ， 恢 复 模 式 就 结束 了 。 状 态 
同步 保证 了 领导 者 和 其 他 服务 器 具有 相同 的 系统 状态 。 


可 


一 旦 领导 者 和 多 数 的 跟随 者 进行 了 状态 同步 ， 它 就 可 以 开始 广播 消息 了 ， 即 进入 广播 状态 。 这 时 候 当 一 个 服务 器 加 入 ZooKeeper 服 务 中 ， 它 会 在 恢复 模式 下 启动 ， 发 现 领导 者 ， 并 和 领导 者 进行 状态 
步 。 待 到 同步 结束 ， 它 也 参与 消息 广播 。ZooKeeper 服 务 一 直 维 持 在 广播 状态 ， 直 到 领导 者 崩溃 了 或 者 领导 者 失去 了 大 部 分 的 跟随 者 支持 。 广 播 模式 类 似 于 分 布 式 事务 中 的 两 阶段 提交 : 即 领导 者 提起 一 个 
决议 ， 由 跟随 者 进行 投票 ， 领 导 者 对 投票 结果 进行 计算 并 决定 是 否 通过 该 决议 ， 如 果 通 过 就 执行 该 决议 (事务 ) ， 否 则 什么 也 不 做 。 


广播 模式 需要 保证 决议 按 顺序 处 理 ， 因 此 ZooKeeper 采 用 了 递增 的 事务 id 号 (zxid) 来 保证 。 所 有 的 提议 都 在 被 提出 的 时 候 加 上 了 zxid。 实 现 中 zxid 是 一 个 64 位 的 数字 ， 其 中 高 32 位 是 epoch， 用 来 标 
识 领 导 者 关系 是 否 改 变 ， 每 有 一 个 领导 者 被 选 出 来 ， 它 都 会 有 一 个 新 的 epoch， 低 32 位 是 个 递增 计数 。 


M 


2. 数 据 模型 
ZooKeeper 拥 有 一 个 分 层 的 命名 空间 ， 这 个 和 标准 的 Unix 文 件 系 统 非常 相似 ， 如 图 9-8 所 示 。 


从 图 9-8 中 ， 我 们 可 以 看 出 ZooKeeper 有 一 个 类 似 于 Unix 文 件 系 统 的 数据 模型 ， 采 用 了 树 形 层次 结构 ， 树 中 的 每 个 节点 都 被 称 为 ZNode (ZooKeeper 数 据 节 点 ) 。 可 以 将 ZNode 视 为 类 似 Unix 传 统 系 
统 中 的 文件 ， 但 它们 可 以 有 子 节点 ;也 可 将 它们 视 为 目录 ， 但 它们 可 以 有 与 其 相关 的 数据 。 
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图 9-8 ZooKeepet 数 据 模型 图 
ZooKeeper 命 名 空间 中 每 个 节点 使 用 路 径 来 标识 ， 如 同 Unix 系 统 中 的 文件 路 径 ， 必 须 用 绝对 路 径 ， 因 此 路 径 必 须 由 “/” 字 符 来 开头 。 
ZooKeeper 设 计 用 来 存储 协调 数据 (比如 状态 信息 、 配 置 、 位 置信 息 等 ) ， 所 以 每 个 节点 上 关联 的 数据 通常 都 比较 小 ， 一 般 几 字 节 到 几 干 字 节 。 每 个 节点 维护 一 个 状态 结构 ， 包 括 数据 变更 版 本 、 


ACL (访问 控制 列表 ) 变更 版 本 、 时 间 戳 、 数 据 长 度 等 信息 ， 每 当 节 点 关联 的 数据 更 新 ， 它 的 数据 变更 版 本 号 就 加 1。 


每 个 节点 上 存储 的 数据 都 要 被 原子 性 地 读 写 操作 ， 即 读 操作 将 获取 与 节点 相关 的 所 有 数据 ， 写 操作 将 替换 掉 节 点 的 所 有 数据 ， 不 能 部 分 读 取 和 修改 。 另 外 ， 每 个 节点 都 和 有 自己 的 访问 控制 列表 ， 这 个 列 
表 限定 了 特定 用 户 对 目标 节点 可 以 执行 的 操作 。 


ZooKeeper 中 的 节点 按 生命 周期 管理 分 为 临时 节点 和 永久 节点 。 


` 临时 节点 : 该 节点 的 生命 周期 依赖 于 创建 它们 的 会 话 。 一 旦 会 话 结束 ， 临 时 节点 将 被 自动 删除 ， 当 然 也 可 以 手动 删除 。 虽 然 每 个 临时 的 节点 都 会 绑 定 到 一 个 客户 端 会 话 ， 但 它们 对 所 有 的 客户 端 都 是 
可 见 的 。 另 外 ， 临 时 节点 不 允许 拥有 子 节点 。 


KAPE. 该 节点 的 生命 周期 不 依赖 于 会 话 ， 并 且 只 有 在 客户 端 显 式 执行 删除 操作 的 时 候 ， 它 们 才能 被 删除 。 


另外 ，ZooKeeper 还 支持 顺序 节点 (无 论 顺 序 还 是 临时 或 永久 ， 都 是 节点 的 一 种 属性 ， 节 点 可 以 有 多 种 属性 ， 比 如 同时 有 顺序 和 临时 属性 ) 。 创 建 此 类 节点 的 时 候 ， 用 户 请 求 在 节点 的 路 径 结尾 添加 一 
个 递增 的 计数 。 这 个 计数 对 于 此 节点 的 父 节 点 来 说 是 唯一 的 ， 它 的 格式 为 ”%10d” (10 位 数字 ,没有 数值 的 数位 用 0 补充 ， 例 如 ”0 000 000 001" ) 。 当 计数 值 大 于 2 147 483 647 时 ， 计 数 器 将 溢出 。 


ZooKeeper 支 持 观 察 (watch) 概念 ， 即 客户 端 可 以 在 节点 上 设置 观察 ,一 旦 此 节点 状态 发 生 改 变 (比如 节点 数据 变更 ， 子 节点 增加 、 删 除 ) 时 将 触发 观察 对 应 的 操作 。 当 观察 被 触发 时 ，ZooKeeper 
将 会 向 客户 端 发 送 且 仅 发 送 一 条 通知 ， 因 为 观察 只 能 被 触 帮 一次， 这样 可 以 减少 网 络 流量 。 


3. 服 务 原 语 

ZooKeeper 提 供 了 很 简单 的 服务 原 语 ， 即 编程 接口 ， 包 括 以 下 操作 : 
- create: 创建 节点 〈 父 节点 必须 存在 ) o 

: delete: 删除 节点 (不 能 有 子 节 点 ) 。 

exists: 测试 节点 是 否 存 在 ， 并 获取 它 的 元 数据 。 

getData: 获取 节点 数据 。 

- setData: 设置 节点 数据 。 

: getChildren: 获取 此 节点 下 所 有 子 节点 列表 。 

. getACL: 获取 节点 ACL。 

setACL: 设置 节点 ACL。 


sync: 等 待 数 据 同步 到 ZooKeepet， 使 客户 端的 节点 视图 和 ZooKeepet 同 步 一 致 。 


9.3.3 ZooKeeper 的 安装 和 配置 


1. 前 提 条 件 


ZooKeeper 和 运行 在 Java 虚 拟 机上， 需要 在 ZooKeeper 和 运行 的 机 器 上 安装 JDK (JDK6 或 以 上 版 本 ) 。 你 可 以 使 用 包 管 理工 具 安 装 或 从 官网 下 载 Java JDK, Java JDK 的 具体 安装 配置 请 参考 其 他 资料 ， 此 处 


不 再 摘 述 。 


2.ZooKeeper 的 安装 
从 Apache 官 网 [1 下 载 一 个 ZooKeeper 发 布 版 本 包 。 


将 tar 包 下 载 到 本 地 ， 解 压 到 当前 目录 ， 示 例如 下 : 


tar xzvf zookeeper-3.4.11.tar.gz 


3.ZooKeeper 的 配置 
ZooKeeper 有 三 种 安装 模式 。 
. 单机 模式 : 单个 主机 上 运行 ZooKeepet 服 务 进程 ， 适 用 测试 、 开 发 环境 。 
. 集群 模式 : 多 个 主机 上 运行 ZooKeeper 服 务 进程 ， 组 成 一 个 服务 集群 ， 适 用 生产 环境 。 
集群 模式 : 单机 上 运行 多 个 服务 器 进程 实例 模拟 集群 ， 适 用 于 测试 环境 ， 这 种 模式 实际 较 少 使 用 ， 故 本 文 不 说 明 。 
(1) ZooKeeper 单 机 模式 配置 
在 ZooKeeper 配 置 目录 下 创建 或 编辑 conf/zoo.cfg 文 件 ， 配 置 字段 如 代码 清单 9-15 所 示 。 


代码 清单 9-15 ”ZooKeeper 单 机 模式 配置 字段 


tickTime=2000 
dataDir-/var/lib/zookeeper 
clientPort-2181 


' tickTime: 基本 事件 单元 ， 以 毫秒 为 单位 。 它 用 来 指示 心跳 ， 最 小 的 会 话 过 期 时 间 为 两 倍 的 tickTime。 
: dataDir: 内 存 数据 库 快 照 文 件 的 存放 位 置 ， 如 果 不 设 置 特定 参数 ， 更 新 事务 日 志文 件 也 被 存储 到 此 位 置 。 
' dientPort: 客户 端 连接 的 监听 端口 
(2) ZooKeeper 集 群 模式 配置 
在 ZooKeeper 安 装 目录 下 创建 或 编辑 conf/zoo.cfg 文 件 ， 配 置 字段 如 代码 清单 9-16 所 示 。 


代码 清单 9-16 ZooKeeper 集 群 模式 配置 字段 


tickTime=2000 
dataDir-/var/lib/zookeeper 
clientPort-2181 
initLimit-5 
syncLimit-2 
server.1-zoo1:2888:3888 
server.2-z002:2888:3888 
server.3-zoo3:2888:3888 


新 增 参 数 说 明 如 下 。 
.initLimit: 此 配置 表示 允许 跟随 者 服务 器 连接 并 同步 到 领导 者 服务 器 的 初始 化 时 间 ， 它 以 tickTime 的 倍数 来 表示 。 当 超过 tickTime*initLimit 时 间 ， 则 连接 失败 。 
“syncLimit: 领导 者 服务 器 与 跟随 者 服务 器 之 间 信 息 同步 允许 的 最 大 时 间 间 隔 ， 如 果 超 过 此 间隔 ， 默 认 跟 随 者 服务 器 与 领导 者 服务 器 之 间 的 链接 断 开 。 


“server.id: 值 格式 为 hostadminPott:electionPort， 它 指示 了 不 同 的 ZooKeepet 服 务 器 的 自身 标识 ， 作 为 集群 的 一 部 分 的 机 器 应 该 知道 集合 体 中 的 其 他 机 器 。ZooKeepet 服 务 器 可 以 从 setvet.id 中 读 取 相 关 信 


息 。 在 服务 器 的 data 目 录 (dataDir 参 数 所 指定 的 目录 ) 下 创建 一 个 文件 名 为 myid 的 文件 ， 这 个 文件 中 仅 含 有 一 行内 容 ， 指 定 的 是 自身 的 id 值 。 比 如 服务 器 “1” 应 该 在 myid 文 件 中 写 入 “1”。 这 个 数值 必须 是 


集合 体 中 唯一 的 ， 且 大 小 在 1 到 255 之 间 。 这 一 行 配置 中 ， 管 理 端口 (adminPort) 是 跟随 者 服务 器 连接 到 领导 者 服务 器 的 端口 ， 选 举 端口 (electionPort) 是 用 来 进行 领导 者 选举 的 端口 。 在 这 个 例子 中 ， 每 台 


机 器 


器 的 ZooKeepet 服 务 器 使 用 三 个 端口 ， 分 别 是 : clientPort: 2181, adminPort: 2888, electionPort: 3888. 


(3) ZooKeeper 服 务 启动 


进入 ZooKeeper 安 装 目录 下 的 bin 子 目录 ， 执 行 如 下 脚本 启动 ZooKeeper 服 务 : 
sudo ./zkServer.sh start 


单机 模式 下 查看 ZooKeeper 服 务 状态 的 命令 示例 如 代码 清单 9-17 所 示 。 


代码 清单 9-17 ZooKeeper 服 务 状态 查询 命令 


$ ./zkServer.sh status 

JMX enabled by default 

Using config: /etc/zookeeper/conf/zoo.cfg 
Mode: standalone 


查询 命令 的 返回 结果 显示 此 ZooKeeper 服 务 器 配置 为 单机 模式 ， 正 常 运 行 。 
集群 模式 下 查看 ZooKeeper 服 务 状 态 的 命令 示例 如 代码 清单 9-18 所 示 。 


代码 清单 9-18 ZooKeeper 服 务 状态 查询 命令 


$ ./zkServer.sh status 

JMX enabled by default 

Using config: /etc/zookeeper/conf/zoo.cfg 
Mode: leader 


查询 命令 的 返回 结果 显示 此 ZooKeeper 服 务 器 配置 为 集群 模式 ， 作 为 领导 者 角色 正常 运行 。 


[1] http://zookeeper.apache.org/releases.htmlo 


9.3.4. ZooKeeper 典 型 应 用 


下 面 介 绍 使 用 ZooKeeper 提 供 的 服务 原 语 来 实现 配置 管理 、 分 布 式 锁 、 群 组 这 些 典型 应 用 ， 更 多 的 应 用 场景 实现 请 参考 官网 文档 [。 


1. 配 置 管 理 
分 布 式 应 用 部 署 在 多 台 机 器 上 ， 一 般 都 有 公共 配置 ， 要 逐个 改变 配置 就 变 得 很 不 方便 。 可 以 把 这 些 配置 信息 作为 某 数据 节点 的 数据 保存 到 ZooKeeper 中 ， 数 据 节点 树 如 图 9-9 所 示 。 
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/ 


Config Data 


/Configuration 


watch — watch ^7 watch 


Client Client Client 


OtherApp 


OtherApp 


图 9-9 ”配置 管理 数据 节点 树 图 


ConfigApp 


由 一 个 客户 端 作为 配置 管理 程序 调用 create 创 建 这 个 配置 节点 和 setData 更 新 此 节点 上 配置 数据 ， 其 他 客户 端 应 用 程序 调用 getData 读 取 此 节点 上 数据 获取 配置 信息 ， 并 对 这 个 目录 节点 进行 监听 ， 一 旦 
新 的 配置 信息 应 用 到 系统 中 ， 这 就 实现 了 分 布 式 应 用 程序 的 集 


J 


配置 信息 发 生变 化 ， 即 此 配置 节点 数据 变更 ， 每 个 客户 端 程序 都 会 收 到 ZooKeeper 的 通知 ， 然 后 客户 端 调用 getData 从 ZooKeeper 获 取 此 节点 
中 配置 管理 。 


2. 分 布 式 锁 


分 布 式 锁 服 务 可 以 分 为 两 类 。 
- 保持 独占 : 即 锁 同时 只 被 一 个 用 户 占用 ， 锁 占用 期 间 其 他 用 户 再 申请 锁 则 返回 失败 。 实 现 流程 如 下 : 我 们 将 ZooKeepet 上 的 一 个 节点 看 作 是 一 把 锁 ， 通 过 cteate 节 点 的 方式 来 实现 。 即 所 有 客户 端 都 去 


创建 /Lock 节 点 ， 由 于 ZooKeepet 保 证 节点 的 唯一 性 ， 只 有 一 个 客户 端 可 以 创建 此 节点 ， 最 终 成 功 创建 的 那个 客户 端 即 拥有 了 这 把 锁 。 用 完 后 删除 看 自己 创建 的 /Lock 节 点 就 释放 出 锁 。 


* 控制 时 序 : 即 申请 锁 的 用 户 按 发 送 请 求 的 前 后 顺序 依次 可 以 获取 到 锁 。 实 现 方式 如 下 : 预先 创建 父 节点 /Lock， 所 有 客户 端 在 它 下 面 创建 临时 顺序 编号 子 节点 ， 编 号 最 小 的 获得 锁 ， 用 完 后 删除 ， 依 次 


处 理 ， 所 有 客户 端 可 以 按 序 获取 ， 数 据 节点 树 如 图 9-10 所 示 。 
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图 9-10 分布 式 共享 锁 数 据 节点 树 图 


获取 锁 流程 如 下 : 
1) 客户 端 调用 create 创 建 一 个 路 径 名 为 “/Lock/lock-” 的 节点 ， 并 将 此 节点 设置 为 顺序 和 临时 属性 :; 
2) 调用 getChildren 获 取 /Lock 父 目录 节点 下 所 有 子 节点 信息 ， 不 设置 观察 点 ; 


3) 如 果 步 骤 1 中 创建 的 节点 名 中 序号 后 缀 数值 是 所 有 子 目 录 下 最 小 值 ， 此 客户 端 就 获取 锁 ， 退 出 流程 ; 

4) 否则 客户 端 调用 exists 查 询 /Lock 父 目录 下 比 本 节点 名 中 序号 后 缀 数值 小 1 的 节点 ， 同 时 设置 观察 点 ; 

5) 如 果 exists 返 回 false， 跳 转 到 步骤 2;， 否 则 等 待 步 骤 4 没 置 的 观察 点 触发 的 对 应 节点 删除 通知 。 

释放 锁 流 程 如 下 : 

客户 端 主 动 删除 步骤 1 中 创建 的 锁 节点 或 者 客户 端 与 ZooKeeper 服 务 器 的 连接 断 开 ， 其 所 创建 的 锁 节点 被 自动 删除 。 
3. 群 组 


组 群 管理 主要 包括 检测 组 成 员 的 加 入 和 退出 、 选 举 群 主 。 数 据 节 点 树 如 图 9-11 所 示 。 


ZooKeeper Service 


/member-0000000001 


/member-0000000002 


4 Imember-000000000X 


— /member-0000000003 


register , register / register, register 


Client Client Client Client 


图 9-11 组 群 数据 节点 树 图 
加 入 组 群 流程 : 
1) 客户 端 在 一 个 父 目 录 “Group” 下 创建 一 个 临时 和 顺序 属性 的 节点 “member-x” (x 表示 自动 分 配 的 序号 ) ; 
2) 监听 父 节点 ， 调 用 getChildren 可 以 获取 父 目 录 节 点 下 所 有 兄弟 节点 信息 ; 
3) 如 果 有 新 的 兄弟 节点 被 创建 ， 所 有 其 他 客户 端 收 到 有 新 的 成 员 加 入 组 群 的 通知 。 


退出 组 群 流程 : 


选举 群 主 流程 : 


参照 上 面 的 分 布 式 锁 获取 流程 ， 客 户 端 都 申请 锁 ， 成 功 获 取 锁 的 客户 端 成 为 群 主 ， 即 编号 最 小 的 节点 选举 为 群 主 。 一 旦 群 主 异 常 导致 和 ZooKeeper 的 连接 断 开 ， 或 群 主 主动 释放 锁 放 痉 群 主角 色 ， 其 他 
客户 端 重新 开始 以 上 流程 选 出 新 的 群 主 。 


[1] http:/ /zookeepet.apache.org/doc/current/recipes.html.; 


9.3.5 NodepoolrB[&FBZooKeeperzn/l 


Nodepool builder 模 块 会 定期 构建 系统 镜像 ， 并 把 构建 的 镜像 信息 保存 到 ZooKeeper 中 。Node-pool 使 用 ZooKeeper 保 存 镜像 信息 的 数据 节点 树 图 如 图 9-12 所 示 。 


ZooKeeper Service 


/nodepool 


images 


nodepool- | | /builds 


builder 1 -> /lock 


1 [PM /0000000002 


nodepool- |.- 


builder2 


/0000000001 


/build-req 


hmage-name2 


图 9-12 ”Nodepool 使 用 ZooKeepet 保 存 镜像 信息 的 数据 节点 树 图 


Builder 使 用 ZooKeeper 保 存 构建 的 镜像 信息 大 致 流程 如 下 : 


1) Builder 创 建 /nodepool/images 目 录 节 点 ， 读 取 配 置 文件 获取 需要 构建 的 各 镜像 信息 ， 在 /nodepool/images 节 点 下 以 镜像 名 作为 节点 名 创建 各 镜像 节点 ， 如 /nodepool/images/ubuntu-trusty, 
在 镜像 目录 节点 下 再 创建 builds 子 目录 节点 ; 


2) 在 某 镜像 节点 的 builds 子 目录 节点 下 申请 独占 锁 (参见 前 节 分 布 式 锁 说 明 ) 。 如 果 获 取 锁 成 功 ， 在 builds 子 目录 节点 下 创建 镜像 构建 节点 ， 节 点 属性 为 顺序 节点 ， 这 样 可 以 保证 最 大 数值 的 节点 名 对 
应 节点 是 最 新 的 镜像 构建 节点 ， 同 时 将 构建 的 镜像 格式 、 构 建 时 间 、 节 点 状态 (building) 等 信息 写 入 此 节点 数据 ， 当 镜像 构建 命令 执行 完毕 后 ， 将 节点 状态 更 新 为 ready， 重 新 写 入 此 节点 数据 ; 如 果 
获取 锁 失 败 ， 则 继续 后 面 步骤 ， 


3) 对 其 他 镜像 节点 继续 执行 步骤 2， 直 到 所 有 镜像 节点 都 执行 完 以 上 操作 。 
通过 ZooKeeper 自 带 的 客户 端 脚本 程序 连接 到 ZooKeeper 服 务 器 可 以 查看 相应 信息 ， 示 例如 代码 清单 9-19 所 示 。 


代码 清单 9-19 ”Nodepool 在 ZooKeeper 中 保存 的 镜像 信息 示例 


# 进入 ZooKeeper 包 安 装 目录 下 bin 目录 


$ cd /usr/share/zookeeper/bin 


# 通过 ZooKeeper 客户 端 程序 登录 本 机 的 ZooKeepe 服务 
$ ./zkCli.sh -server 127.0.0.1:2181 

Connecting to 127.0.0.1:2181 
Welcome to ZooKeeper! 
JLine support is enabled 
[zk: 127.0.0.1:2181(CONNECTING) 0] 
WATCHER:: 


WatchedEvent state:SyncConnected type:None path:null 


+ 查看 upunt-trusty 这 个 镜像 的 构建 目录 节点 下 子 节点 列表 
[zk: 127.0.0.1:2181(CONNECTED) 7] ls /nodepool/images/ubuntu-trusty/builds 
[lock, 0000000036, 0000000024] 


# 查看 ubuntu-trusty 这 个 镜像 对 应 的 0000000036 构 建 子 节点 的 数据 ，buildqing 表 示 此 镜像 在 构建 中 
[zk: 127.0.0.1:2181(CONNECTED) 10] get /nodepool/images/ubuntu-trusty/builds/ 


0000000036 
("state": "building", "formats": "qcow2", "builder": "nodepool.cibook.oz", 


"state time": 1516475486.587287] 


# 查看 ubuntu-trusty 这 个 镜像 对 应 的 0000000024 构 建 子 节点 的 数据 ，ready 表 示 此 镜像 构建 完成 
k: 127.0.0.1:2181(CONNECTED) 11] get /nodepool/images/ubuntu-trusty/builds/ 


[z 

0000000024 

{"state": "ready", "formats": "qcow2", "builder": "nodepool.cibook.oz", 
# 退出 ZooKeepez 客 户 端 程序 

[ 


ZK: 127.0.0.1:2181(CONNECTED) 15] quit 


Quittinghttp://www.hzcourse.com/resource/readBook?path-/openresources/teach ebook/uncompressed/17933/OEBPS/Text/... 


94 本章 小 结 


本 章 对 Gearman、ZeroMQ 和 ZooKeeper 进 行 了 简单 介绍 ， 并 通过 一 些 简单 的 示例 代码 来 说 明 如 何 使 用 它们 。 如 果 读 者 希望 对 它们 有 进一步 的 深入 了 解 ， 请 参考 相关 资料 。 


第 10 章 ”社区 CIMCD 实 践 


前 面 的 章节 详细 介绍 了 Openstack CIMCD 的 框架 及 各 组 件 的 使 用 ， 本 章 将 基于 这 套 解决 方案 重点 介绍 下 企业 内 部 的 实践 : 首先 介绍 如 何 利用 社区 的 配置 搭建 一 套 单 节点 的 系统 ， 有 个 总 体 直观 印象 ; 然 
后 介绍 如 何 利用 该 系统 定制 企业 级 CIMCD。 


10.1 Puppet 简 介 


在 介绍 实践 之 前 ， 我 们 先 简 单 介绍 一 人 Puppet 配 置 管理 工具 。 


Puppet 是 由 Puppetlabs 公 司 开 发 的 系统 管理 框架 和 工具 集 ， 于 2005 年 正式 面世 ， 广 泛 应 用 于 IT 服务 的 自动 化 管理 。 由 于 良好 的 声明 式 语 言 和 易于 扩展 的 框架 设计 以 及 可 重用 可 共享 的 模块 ， 使 得 许多 
大 型 知名 公司 (比如 Google、Cisco、Twitter、RedHat 等 ) 和 机 构 在 其 数据 中 心 的 自动 化 管理 中 用 到 了 Puppet。2012 年 5 月 ，Puppetlabs 率 先 与 OpenStack 合 作 ， 使 Puppet 在 OpenStack 中 发 挥 着 重要 
的 作用 : OpenStack 基 础 设施 团队 将 其 用 于 Wiki、Storyboard 任 务 跟踪 、CI 系 统 等 的 运 维 管 理 中 ; 社区 提供 了 多 个 代码 库 用 于 OpenStack 各 服务 的 自动 化 部 署 和 管理 ， 如 puppet-nova、puppet- 
neutron、puppet-cinder 等 ; 此 外 ，Cisco、RedHat、Mirantis 等 多 家 公司 的 OpenStack 发 行 版 或 部 署 工具 中 均 使 用 到 了 Puppet。 可 以 说 ， 不 了 解 Puppet 就 无 法 深入 理解 OpenStack 的 基础 设施 及 服务 


的 自动 化 部 署 管 理 。 


10.1.1 概述 


Puppet 是 一 种 Linux、Unix、Windows 平 台 的 集中 配置 管理 工具 ， 使 用 自 有 的 Puppet 描 述 语言 ， 可 管理 配置 文件 、 用 户 、cron 任 务 、 软 件 包 、 系 统 服务 等 。Puppet 把 这 些 系统 实体 称 之 为 资源 ， 每 种 
资源 有 不 同 的 属性 ， 因 此 Puppet 语 言 就 是 描述 这 些 资 源 的 属性 以 及 资源 之 间 关 系 的 语言 。Puppet 的 设计 目标 是 简化 对 这 些 资源 的 管理 以 及 妥善 处 理 资源 间 的 依赖 关系 。 


Puppet 与 其 他 手工 操作 工具 有 一 个 最 大 的 区 别 就 是 Puppet 的 配置 具有 稳定 性 ， 它 会 让 你 的 系统 状态 同 配置 文件 所 要 求 的 状态 保持 一 致 ， 因 此 你 可 以 多 次 执行 Puppet。 一 旦 你 更 新 了 配置 文 


件 ，Puppet 就 会 根据 配置 文件 来 更 改 你 的 资源 状态 。 


- 


首先 了 解 下 几 个 重要 概念 ， 有 助 于 读者 理解 Puppet 的 工作 模式 。 

1. 资 源 

定义 目标 状态 的 核心 组 件 ; 核心 资源 包括 : package、group、user、file、exec、cron、service 等 。 代 码 清单 10-1 定 义 了 一 个 文件 资源 ， 指 定 该 文件 为 /etc/passwd， 归 属 的 用 户 和 组 为 root， 没 有 
则 创建 。 


代码 清单 10-1 ”文件 资源 


file ( '/etc/passwd': 
owner => 'root', 
group => 'root', 

ensure => present, 


} 


一 组 资源 的 集合 。 如 代码 清单 10-2 所 示 : 定义 一 个 Linux 类 ， 包 含 file 和 package 两 个 资源 。 


代码 清单 10-2 Linux% 


class linux { 

file ( '/etc/passwd': 
owner => 'root', 
group => 'root', 
ensure => present, 


) 
package ('httpa': 
ensure => installed, 


) 


3. 模 块 
以 资源 为 核心 ， 是 类 的 集合 ， 如 module1、module2。 一 个 模块 下 通常 包括 如 下 目录 和 文件 : manifests、files、templates 和 metadata.json。 代 码 清单 10-3 表 示 一 个 模块 的 目录 结构 。 


代码 清单 10-3 ”模块 


$ tree 


manifests 


implementation/ 
init.pp 


other class.pp 
files/ 
lib/ 
templates/ 
metadata.json 
README .md 
spec/ 
tests/ 


. manifests/: 定义 并 保存 资源 ， 必 须要 包括 一 个 init.pp 的 文件 ， 这 是 该 模块 的 初始 (入口 ) 文件 ， 导 入 一 个 模块 的 时 候 ， 会 从 initpp 开 始 执行 。 可 以 把 所 有 的 代码 都 写 到 initpp 里 面 ， 也 可 以 分 成 多 个 pp 
文件 ，init pp 再 去 包含 其 他 文件 。 


: files/: 静态 文件 目录 ， 可 以 通过 访问 puppet:///modules/module_name/file 获 取 文 件 内 容 。 
templates/: 模板 文件 目录 。 


: metadatajson: 该 模块 的 元 数据 。 


puppet 利 用 模块 + 节点 的 方式 ， 实 现 目标 状态 的 定义 ; 节点 的 管理 一 般 存 贮 在 文件 /etc/puppet/manifests/site.pp 里 。 如 代码 清单 10-4 所 示 ， 定 义 一 个 域名 为 www1.example.com 的 节点 ， 引 用 两 个 
模块 common 和 apache 的 资源 状态 。 


代码 清单 1 0-4 节点 


node 'wwwl.example.com' { 
include common 
include apache 


5.Manifest 

清单 ， 用 于 定义 并 保存 资源 ， 是 一 个 资源 组 织 工具 ; 

6.Facter[] 

收集 节点 信息 。 代 码 清单 10-5 显 示 通 过 facter 命 令 获 取 到 的 当前 主机 信息 。 


代码 清单 10-5  Facter 


$ facter 

architecture => amd64 

augeasversion => 1.4.0 
blockdevice sda model => TOSHIBA MQOTACFO 
blockdevice sda size => 500107862016 
blockdevice sda vendor => ATA 
blockdevices => sda 

dhcp servers => {"system"=>"10.67.14.37", "enp0s25"=>"10.67.14.37", "wlp3s0"=> 

"192.168.1.1"} 

domain => zte.intra 

facterversion => 2.4.6 

filesystems => ext2,ext3,ext4,squashfs,vfat 

fqdn => opnfv.zte.intra 

gid => zte 

hardwareisa => x86 64 

hardwaremodel => x86 64 

hostname => opnfv 

id => zte 

http: //www.hzcourse.com/resource/readBook?path-/openresources/teach ebook/uncompressed/17933/0EBPS/Text/... 


7.Hiera 


Manifest 同 时 包含 静态 代码 和 动态 数据 ， 动 态 数据 需要 根据 具体 情况 赋值 ， 因 此 将 动态 数据 从 Manifest 中 剥离 出 来 ， 使 用 Hiera 将 数据 存储 在 外 部 的 文件 中 ， 根 据 实 际 情况 赋值 。 在 编译 时 ，Manifest 
通过 Hiera 动 态 查 询 所 需 的 值 ， 然 后 加 载 到 伪 代 码 (catalog) 中 。 比 如 代码 清单 10-6 表 示 在 编译 jenkins.cibook.oz 的 catalog 时 ， 需 要 通过 Hiera 动 态 查询 配置 数据 。 


代码 清单 10-6 ”使 用 Hiera 


node 'jenkins.cibook.oz' { 


class ( '::openstackci::jenkins node': 
vhost name => $vhost name jenkins, 
project config repo => hiera('project config repo'), 
serveradmin => hiera('serveradmin', "webmaster@$ {vhost name jenkins)"), 
jenkins version => hiera('jenkins version', 'present'), i 
jenkins vhost name => hiera('jenkins vhost name', 'jenkins'), 
jenkins username -» hiera('jenkins username', 'jenkins'), 
jenkins password -» hiera('jenkins password', 'XXX'), 
jenkins ssh private key => hiera('jenkins ssh private key'), 
jenkins ssh public key => hiera('jenkins ssh public key'), 
log server => hiera('log server'), 


# «http: //www.hzcourse.com/resource/readBook?path-/openresources/teach ebook/uncompressed/17933/OEBPS/Text/...» 


而 Hiera 从 哪些 文件 中 读 取 这 些 动态 配置 数据 ， 需 要 通过 Hiera 的 配置 文件 指定 ， 即 配置 /etc/puppet/hiera.yaml， 如 代码 清单 10-7 所 示 ， 表 示 从 目录 /etc/puppet/environments 下 查找 common 文 
件 ， 文 件 类 型 为 yaml。 


代码 清单 10-7 “Hiera 配 置 文件 


:backends: 

- yaml 
:logger: console 
:hierarchy: 

- common 


:yaml: 
:datadir: /etc/puppet/environments 


具体 参数 详解 参见 官方 文档 中。 


[1] https:/ /docs.puppet.com/ factet/ 。 
[2] https:/ /docs.puppet.com/hiera/ 。 


10.1.2 基础 架构 


Puppet 支 持 两 种 工作 模式 : Master/Agent 和 Stand-alone 模 式 ， 下 面 简单 介绍 一 下 两 种 模式 的 工作 方式 。 


1.Master/Agent 


Master/Agent 即 客户 端 和 服务 器 交互 模式 ， 通 过 Master 集 中 式 管理 。Puppet master 上 只 运行 Puppetmaster 服 务 ， 简 称 Puppet 服 务 器 端 ; Puppet agent 上 只 运行 Puppet 服 务 ， 简 称 Puppet 客 户 


EXIT] 
Uo 


Puppet 客 户 端 首先 会 连接 到 Puppet 服 务 器 端 ， 并 且 通 过 Facter 工 具 获取 客户 端的 基本 配置 信息 并 发 送 给 服务 器 端 。 服 务 器 端 通过 分 析 客 户 端的 主机 名 ， 通 过 node 定 义 ， 找 到 该 主机 的 配置 代码 ， 然 后 
编译 配置 代码 为 catalog， 把 编译 好 的 catalog 发 回 客 户 端 ， 客 户 端 执行 代码 完成 配置 ， 并 且 把 代码 执行 情况 反馈 给 Puppet 服 务 器 端 。 


流程 图 如 图 10-1 所 示 。 


请 求 主机 catalog， 同 
时 发 送 主 机 名 和 facts 


查询 请 求 者 的 站 点 清单 


classes EINE 


classes 
编译 


( catalog ) 


PARIS 
(catalog) 


执行 目标 状态 


ri 


图 10-1  Master/ Agent-I- 4E 1€ X, 


这 种 模式 下 的 客户 端 和 服务 器 端 是 通过 ss| 连 接 来 保证 安全 性 的 ，ssl 连 接 用 到 的 证 书 是 x.509 证 书 。Puppet 会 自己 生成 证 书 。ss| 在 连接 的 时 候 ， 会 对 比 证 书 里 面 的 域名 字 是 否 和 主机 名 匹配 ， 如 果 不 匹 配 
就 会 报 证 书 验 证 错误 。 


下 面 列举 了 几 个 Master/Agent 模 式 的 特点 : 
集中 式 管 理 ， 易 于 更 新 配置 、 上 报 和 保存 数据 。 
: 基于 ssl 的 连接 ， 安 全 性 更 好 。 


: Puppet agent 代 理 不 编译 自己 的 catalog， 从 而 为 其 指定 的 任务 提供 更 多 


» 
kajo 


- 所 有 的 配置 和 Puppet 模 块 安装 都 在 Master 节 点 上 ， 对 性 能 要 求 较 高 ， 需 要 一 个 专用 的 服务 器 。 

“ 需要 良好 的 网 络 连接 。 

在 生产 环境 中 ， 一 般 都 采用 Master/Agent 模 式 。 

2.Stand-alone 

stand-alone 即 单机 模式 ， 只 运行 Puppet 服 务 ， 收 集 配 置信 息 、 编 译 、 执 行 配置 代码 和 上 报 执 行 结 果 都 在 本 机 完成 。 


流程 图 如 图 10-2 所 示 。 


manifest manifest manifest 


ff I 


( catalog ) 


ANZ E 1H] 


执行 目标 状态 


目标 状态 


图 10-2 Stand-alone 工 作 模 式 
总 体 来 说 ，Stand-alone 模 式 也 可 以 完成 Master/Agent 模 式 的 相同 的 功能 。 用 户 选 择 何 种 模式 工作 ， 可 以 根据 需要 在 安全 性 和 其 他 方面 做 一 些 权衡 。 


本 节 只 简单 介绍 了 Puppet 的 工作 原理 ， 其 他 详细 信息 可 以 到 官网 上 学 习 [1], 


[1] https:/ /puppet.com/。 


10.2 SIAE 


要 把 这 样 一 个 多 组 件 的 复杂 的 Cl 系统 手动 部 署 和 配置 起 来 是 比较 困难 的 ， 而 且 手 动 部 署 和 配置 还 会 增加 人 为 误 操 作 的 风险 ， 降 低 部 署 成 功率 。 社 区 提供 了 一 个 自动 化 的 单机 [1 部署 配 置 指导 ， 框 图 如 图 
10-3 所 示 ， 即 使 用 Puppet Stand-alone 的 工作 模式 ， 把 Zuul、Jenkins 和 Nodepoo 人 部署 安装 在 一 台 服 务 器 上 ， 日 志 服 务 器 部 署 在 另 一 台 服 务 器 上 。 


我 们 先 从 简单 的 入 手 ， 搭 建 这 样 一 套 CI/CD 系 统 。 


[1] https://docs.openstack.org/infra/openstackci o 


10.2.1 前 期 准备 


1) 在 GitHub 上 fork 两 个 代码 库 。 


CI Master 


Nodepool Logserver 


Nodepool 
Zuul Jenkins : 
Scheduler 


Gearman | ZeroMQ Nodepoolbuilder 
Zuul Merger Plugin Plugin Po 


Zookeeper 


图 10-3 单机 部 署 
- openstack-infra/system-config! : 包含 CI 各 组 件 的 部 署 信息 。 
` openstack-infra/project-config"!: 包含 需要 管理 的 项 目 和 服务 的 配置 数据 。 
Qu 
openstack-infra/project-configA fib JE] 3-2» X, 3&4& M before-jenkins-conf ig-removed4s 4& 2 X 
2) 可 用 的 OpenStack 环 境 : 用 于 Nodepool| 创 建 节点 资源 池 ， 需 要 创建 flavor、 和 租户、 租户 网 络 及 外 部 网 络 。 
3) 两 台 服 务 器 : 可 以 是 虚 机 ， 也 可 以 是 物理 机 ，8 核 8G 内 存 80G 磁 盘 ， 一 台 作 为 日 志 服 务 器 ， 一 台 作 为 CI| Master, 
4) Gerrit 服 务 器 : 使 用 现 有 的 Cerrit 服 务 器 ， 注 册 CI 用 户 ， 用 户 设置 中 添加 公 钥 用 于 Zuul 通 过 该 用 户 连接 Gerrit， 并 赋予 该 用 户 接收 事件 流 和 合并 代码 的 权限 。 


[1] https://git.openstack.org/openstack-infra/system-conf igo 


[2] https://git.openstack.org/openstack-infra/project-conf igo 


10.2.2 ZRA 


1. 安 装 和 配置 Puppet 

(1) 安装 Puppet 

克隆 system-conf ig 库 到 CI Master/ 日 志 服 务 器 上 ， 运 行 System-conf ig/install puppet.sh 脚 本 自动 安装 。 
(2) 安装 Puppet 模 块 


运行 脚本 system-conf ig/install modules.sh 安 装 所 需 的 Puppet 模 块 。 具 体 需要 安装 哪些 模块 ， 是 在 system-conf ig/modules.env 文 件 中 指定 ， 这 里 我 们 暂时 不 做 裁剪 ， 采 用 社区 的 默认 配置 。 这 一 
步 耗 时 比较 长 ， 因 为 在 线 下 载 的 模块 比较 多 。 安 装 完成 后 ， 查 看 /etc/puppet/modules/ 目 录 ， 可 看 到 安装 了 哪些 模块 。 


(3) 配置 “Puppet Stand-alone” 工 作 模 式 
准备 节点 配置 文件 site.pp， 部 署 代 码 中 有 动态 配置 数据 ， 还 需要 准备 数据 配置 文件 common.yaml 和 Hiera 配 置 文件 hiera.yaml。 
相关 文件 在 项 目 puppet-openstackcil1] 的 contrib 目 录 下 ， 该 项 目 是 Puppet 的 openstackci 模 块 ， 已 在 上 一 步 中 安装 。 

. 对 于 搭建 日 志 服 务 器 ， 如 代码 清单 10-8 所 示 ， 复 制 文 件 到 环境 的 配置 目录 下 : 


代码 清单 10-8 日 志 服 务 器 配置 文件 


cp /etc/puppet/modules/openstackci/contrib/hiera.yaml /etc/puppet 
cp /etc/puppet/modules/openstackci/contrib/log server site.pp 
/etc/puppet/manifests/site.pp B 
cp /etc/puppet/modules/openstackci/contrib/log server data.yaml ^ 
/etc/puppet/environments/common. yaml 


对 于 搭建 CI Mastet 服 务 器 ， 如 代码 清单 10-9 所 示 ， 复 制 文件 到 环境 的 配置 目录 下 : 


代码 清单 10-9 CI Master 服 务 器 配置 文件 


cp /etc/puppet/modules/openstackci/contrib/hiera.yaml /etc/puppet 
cp /etc/puppet/modules/openstackci/contrib/single node ci site.pp \ 
/etc/puppet/manifests/site.pp 
cp /etc/puppet/modules/openstackci/contrib/single node ci data.yaml \ 
/etc/puppet/environments/common.yaml 


节点 配置 文件 site.pp 和 动态 数据 配置 文件 ommon.yaml 是 自动 化 部 署 的 重点 配置 ， 下 面 是 具体 节点 安装 的 详细 介 
日 志 服务 器 搭建 

(1) 动态 数据 配置 

日 志 服 务 器 的 动态 数据 配置 common.yaml 比 较 简单 ， 如 代码 清单 10-10 所 示 ， 带 # 的 参数 表示 不 是 必须 配置 的 。 


代码 清单 10-10 ”日志 服务 器 动态 配置 


# See parameter documetation inside http://www.hzcourse.com/resource/readBook?path-/openresources/teach ebook/uncompressed/17933/OEBPS/Text/../manifests/single node ci.pp 
# Fields commented out have reasonable default values 

domain: .OZ 

jenkins ssh public key: your-jenkins-public-key-no-whitespace 

#swift authurl: — — 

swift user: 


#swift key: 
#swift tenant name: 
«swift region name: 


*swift default container: 


: domain: 日 志 服务 器 的 域名 信息 。 

jenkins_ssh_public_key: 用 于 Jenkins 访 问 日 志 服务 器 的 公 铀 。 
其 他 Swift 相关 的 配置 是 可 选项 ， 用 于 日 志文 件 的 对 象 和 存储， 这 些 可 以 不 配置 。 
(2) 节点 配置 
日 志 服 务 器 的 部 署 入 口 文件 site.pp 如 代码 清单 10-11 所 示 。 


代码 清单 10-11 日 志 服 务 器 节点 配置 


node default { 
class ( '::openstackci::logserver': 
domain => hiera (' domain'), 
jenkins ssh key => hiera('jenkins ssh public key'), 
swift authurl => hiera('swift authurl', Uy 
swift user —» hiera('swift user' "n, 
swift key => hiera(' swift key', IT 
swift tenant name => hiera('swift tenant name', ''), 
swift . region name => hiera('swift . region name' a 
swift default container => hiera('swift default : container' "A 


调用 openstackci 模 块 中 的 logserver 类 完成 该 节点 上 的 所 有 资源 部 署 。 具 体 执行 哪些 资源 操作 可 查看 puppet-openstackci/manifests/logserver.pp， 这 里 不 再 详细 展开 。 
(3) 安装 部 署 


配置 完成 后 运行 如 下 命令 执行 安装 部 署 : 


sudo puppet apply /etc/puppet/manifests/site.pp 


该 命令 执行 时 ， 通 过 hiera 获 取 common.yaml 文 件 中 的 动态 配置 数据 ， 加 载 到 该 节点 的 清单 ， 即 openstackci 模 块 中 的 logserver 类 ， 编 译 成 catalog 执 行 并 上 报 结果 ， 用 户 可 以 根据 终端 输出 查看 执行 结 


部 署 成 功 后 ， 使 用 如 下 命令 验证 服务 器 是 否 可 用 : 


scp -i SJENKINS SSH PRIVATE KEY FILE -o StrictHostKeyChecking-no \ 
$your-log-file jenkinsG«fqdn or ip»:/srv/static/logs/ 


JENKINS_SSH_PRIVATE_KEY_FILE 即 与 配置 文件 中 公 钥 配对 的 私 钥 文件 ，your-log-f ile 是 上 传 的 日 志文 件 。 


文件 上 传 完 成 之 后 ， 通 过 访问 如 下 地 址 查看 上 传 文件 : 


http://<fqdn or ip>/$your-log-file 


3.CI Master 服 务 器 搭建 
(1) 配置 动态 数据 
CI Master 上 动态 数据 配置 common.yaml 如 代码 清单 10-12 所 示 。 


代码 清单 10-12 Cl 服务 器 动态 配置 文件 


# See parameter documentation inside http://www.hzcourse.com/resource/readBook?path-/openresources/teach ebook/uncompressed/17933/OEBPS/Text/../manifests/single node ci.pp 
# Fields commented out have reasonable default values 


#vhost name: 

project config repo: https://github.com/dwj/project-config 
#serveradmin: 

jenkins username: jenkins 

jenkins password: jenkins 

jenkins_ssh private key: your-jenkins-private-key 


j 


enkins ssh public key: your-jenkins-public-key-no-whitespace 


#java args override: 


J 


jb git revision: 1.6.2 


#jjb git url: https://git.openstack.org/openstack-infra/jenkins-job-builder 
gerrit server: gerrit.oz 

#gerrit ssh host key: 

gerrit user: openzeroci 

gerrit user ssh private key: gerrit-user-private-key 

gerrit user ssh public key: gerrit-user-public-key-no-whitespace 

git email: openzeroci@zte.com.cn 

git name: openzeroci 


J 


og server: logs.oz 


#smtp host: 
#smtp default from: 
*smtp default to: 


zuul revision: 2.5.2 
zuul git source repo: https://git.openstack.org/openstack-infra/zuul 


oscc file contents: | 


n 


4 Do Not Edit - Generated & Managed by Puppet 
# 


mysql root password: root123 
mysql nodepool password: root123 


J 
J 
n 
n 


odepool jenkins target: jenkins1 

jenkins api key: # jenkins api key get from Jenkins 

enkins credentials id: # jenkins api key get from Jenkins 

odepool revision: 0.4.0 

odepool git source repo: https://git.openstack.org/openstack-infra/nodepool 


为 了 便于 理解 ， 对 所 有 的 配置 参数 按 组 件 进行 划分 ， 并 分 别 介绍 : 


(a) 公共 配置 


即 所 有 的 组 件 服务 都 需要 用 到 的 参数 配置 ， 具 体 包 括 : 


: project_conftg repo: project-conf ig 仓 库 的 地 址 ， 所 有 CI 组 件 都 需要 读 取 该 仓库 下 和 自己 相关 的 配置 ， 即 准备 工作 中 fo 全 的 仓库 地 址 。 
: vhost_name: 主机 名 称 ， 可 以 不 配 。 
(b) Zuul 相 关 配 置 
gettit_server: Zuul 对 接 的 Gettit 服 务 器 地 址 。 
: gerit ssh host key: Gertit 服 务 器 上 的 公 钥 ， 用 于 Zuul 通 过 ssh 第 一 次 连接 Gerrit 服 务 器 时 不 需要 人 机 交互 。 
- gertit_user: Gettit 用 户 ，Zuul 连 接 Gettit 时 使 用 的 用 户 ， 需 要 提前 在 Gettit 服 务 器 上 创建 。 


， gettit user ssh private key/fegertit user ssh public key: Gettit 用 户 的 密 钥 对 ，Zuul 通 过 ssh 连 接 到 Gettit 服 务 器 时 通过 该 私 钥 鉴 权 ; 公 钥 必须 和 Gettit 用 户 下 配置 的 公 钥 一 致 。 


git emailfegit name: 操作 git 库 的 用 户 和 邮件 地 址 。 

- smtpb_host、smtp_default_from 和 smtp_default_ to: SMTP 相 关 的 配置 ，Zuul 在 测试 完成 后 通过 SMTP 发 送 邮件 通知 ， 可 以 不 配置 。 

- zuul revision fezuul git source repo: Zuul 的 版 本 及 源 仓 库 地 址 ，Puppet 安 装 Zuul 时 即 从 该 仓库 地 址 下 载 对 应 的 版 本 安装 。 

:log server: 日 志 服 务 器 的 地 址 ， 即 上 节 搭 建 的 日 志 服 务 器 的 地 址 ，Zuul 在 返回 当前 变更 的 测试 结果 时 携带 本 次 测试 的 日 志 存 放 路 径 。 
(c) Jenkins 相 关 配 置 

serveradmin: 可 以 不 配置 ， 黑 认 值 为 webmastet${vhost_name} 。 


“jenkins_username 和 jenkins_password: 访问 Jenkins 服 务 器 的 用 户 名 和 密码 ; 如 果 不 是 Jenkins 默 认 的 管理 员 用 户 ， 在 Jenkins 安 装 完成 之 后 ， 需 要 手动 创建 该 用 户 和 密码 。 


.jenkins_ssh_btivate_key 和 jenkins_ssh_public_key: Jenkins 服 务 中 使 用 到 的 密 钥 对 ， 与 上 节 搭 建 日 志 服 务 器 使 用 的 密 钥 对 相同 ， 私 钥 用 于 访问 日 志 服 务 器 以 及 创建 credentials， 公 钥 写 入 Jenkins 的 工作 目录 


: java atgs ovetride: 启动 Jenkins 时 重 写 的 参数 选项 ， 可 以 不 配 。 
: jjb_git_revision 和 jjb_git_url: JJB 的 版 本 及 源 仓库 地 址 ; 可 以 不 配 ， 直 接 使 用 默认 值 https://git.openstack.org/openstack-infra/jenkins-job-builder。 
(d) Nodepool 相 关 配 置 


- oscc, ftle contents: Nodepool 对 接 的 云 环境 ， 参考 配置 如 代码 清单 10-13 所 示 ， 根 据 实际 云 环境 修改 。 


代码 清单 10-13” 云 环境 定义 


louds 


lient: 


force ipv4: true 


zte-pod13: 
profile: internap 
floating ip source: 'neutron' 
auth: 
username: 'ciuser' 
password: 'ciuser' 
project name: 'ciuser' 
auth url: 'http://h13.0z:5000/v2.0' 
regions: 
- name: RegionOne 
values: 
networks: 
- name: admin floating net 
routes externally: true 
- name: net-ci 
nat destination: true 
default interface: true 


: mysql. root. passwordZiemysql nodepool password: toot 用 户 和 hodepool 用 户 访问 数据 库 的 密码 ， 数 据 库 安装 完成 之 后 会 自动 创建 。 


. nodepool jenkins target: 和 Nodepool 对 接 的 Jenkins 名 称 。 


. nodepool revision fenodepool git source repo: Nodepool 的 版 本 及 源 仓库 地 址 ; Puppet 安 装 Nodepool 时 即 从 该 仓库 地 址 下 载 对 应 的 版 本 安装 。 


: jenkins api keyjfejenkins credentials id: 这 两 个 参数 暂且 不 配 ， 待 Jenkins 服 务 器 起 来 之 后 ， 需 要 手动 配置 并 获取 填 入 ， 后 面 讲 Jenkins 的 手动 配置 时 会 提 到 ， 用 于 Nodepool 访 问 Jenkins 服 务 器 。 


(2) 节点 配置 
CI Master 的 部 署 入 口 文件 site.pp 如 代码 清单 10-14 所 示 。 


代码 清单 10-14 CI Master 节 点 配置 


node default { 
4 If the fqdn is not resolvable, use its ip address 
$vhost name = hiera('vhost name', $::fqdn) 


class ( '::openstackci::single node ci': 

vhost name -» $vhost name, 

project config repo => hiera('project config repo'), 

serveradmin => hiera('serveradmin', "webmaster@$ {vhost name)"), 
jenkins version => hiera('jenkins version', 'present'), | 

enkins vhost nam => hiera('jenkins vhost name', 'jenkins'), 
enkins usernam —» hiera('jenkins username', 'jenkins'), 

enkins password => hiera('jenkins password', 'XXX'), 


enkins ssh private key => hiera('j nkins ssh private key'), 
enkins ssh public key => hiera('jenkins ssh public key'), 


LEAL CA EN ON C S SE a E 


ava args overrid -» hiera('java args override', undef), 

gerrit server => hiera('gerrit server', 'review.openstack.org'), 
gerrit user => hiera('gerrit user'), 
gerrit user ssh public key => hiera('gerrit user ssh public key'), 


gerrit user ssh private key => hiera('gerrit user ssh private key'), 


gerrit ssh host key => hiera('gerrit ssh host key', ''), 
git email | => hiera('git email'), 
git name => hiera('git name'), 
log server => hiera('log server'), 
smtp host => hiera('smtp host', 'localhost'), 
smtp default from => hiera('smtp default from', "zuul@$ {vhost name)"), 
smtp default to => hiera('smtp default to', "zuul.reportsG8S$[(vhost- , 
!name)"), 
zuulv2 => hiera('zuulv2', true), 
zuul revision => hiera('zuul revision', "'master'), 
zuul git source repo => hiera('zuul git source repo', https://git.openstack.org/openstack-infra/zuul'), 
oscc file contents => hiera('oscc file contents', ''), 
mysql root password => hiera('mysql root password'), 
mysql nodepool password => hiera('mysql nodepool password'), 
nodepool jenkins target => hiera('nodepool jenkins target', 'jenkins1'), 
jenkins api key => hiera('jenkins api key', 'XXX'), 
jenkins credentials id => hiera('jenkins credentials id', 'XXX'), 
nodepool revision => hiera('nodepool revision', 'master'), 
nodepool git source repo => hiera('nodepool git source repo','https://git.openstack.org/openstack-infra/nodepool'), 
jjb git revision => hiera('jjb git revision', '1.6.2!), 
jjb git url => hiera('jjb git url', 'https://git.openstack.org/openstack-infra/jenkins-job-builder'), 


与 日 志 服 务 器 类 似 , 调 用 openstackci 模 块 中 的 single_node_ci 类 完成 该 节点 上 的 所 有 资源 部 署 。Puppet 模 块 的 调用 关系 如 图 10-4 所 示 。 


:jenkins:: 


master 


openstackci:: 


jenkins master mmm 
:jenkins:: 


job builder 


openstackci:: 
zuul scheduler 
openstackci:: >| zzuul:server 
single node ci 
openstackci:: 


::zuul::merger 
zuul merger 


NodePool 


:inodepool 


openstackci:: 


nodepool 


:inodepool:: 
builder 


F = = = o s m = = = 


图 10-4 单机 部 署 模 块 调用 关系 
具体 执行 哪些 资源 操作 可 查看 puppet-openstackci/manifests/single_node_ci.pp 进 行 了 解 ， 这 里 不 做 详细 展开 。 
(3) 安装 部 署 


运行 部 署 之 前 ， 需 要 在 /etc/hosts 文 件 中 添加 enkins 为 Apache 服 务 使 用 : 


127.0.0.1 localhost jenkins 


运行 如 下 命令 执行 安装 部 署 : 


puppet apply /etc/puppet/manifests/site.pp 


执行 完成 后 所 有 组 件 服务 基本 都 安装 完成 ， 但 是 系统 还 不 能 用 ， 需 要 手工 启动 服务 和 配置 Jenkins。 
(4) 启动 服务 
运行 代码 清单 10-15 所 示 命 令 启动 服务 。 


代码 清单 10-15 ”服务 启动 


udo service apache2 restart 
udo service zuul start 

udo service zuul-merger start 
udo service nodepool start 
udo service nodepool-builder start 
重启 Jenkins 服务 是 为 了 使 插件 完全 安装 可 用 


udo service jenkins restart 


Qsunuuodo 


(5) 配置 Jenkins 
打开 Jenkins UI (http://<host fqdn/ip»:8080/) 进行 手工 配置 。 
(a) 配置 Gearman 


进入 Jenkins 页 面 中 选择 “Manage Jenkins Configure System 一 Gearman Plugin Config”， 配 置 Gearman 的 服务 器 地 址 和 端口 ， 勾 选 “Enable Gearman，” 如 图 10-5 所 示 。 


Gearman Plugin Config 


Gearman Server Host 


Gearman Server Port 


Enable Gearman v 


select to enable Gearman plugin, Unselect to disable 


图 10-5 Gearmandá& 4f Bo X. 
配置 完成 ， 可 单 击 “Test Connection” 测 试 连接 。 
(b) 配置 ZMQ Event Publisher 


进入 Jenkins 页 面 ， 选 择 Manage Jenkins 一 Configure System 一 ZMQ Event Publisher, W "Enable on all Jobs”， 如 图 10-6 所 示 。 


ZMQ Event Publisher 
Enable on all Jobs 


Check if we should publish events for all jobs. 


TCP port to publish on 8888 


Bind to this TCP port and publish events on it 


图 10-6 ZMQ4&Tr BC 
(c) 安全 配置 
默认 情况 下 ，Jenkins 安 装 时 禁用 了 用 户 安全 认证 ， 对 于 外 部 访问 受 限 的 开发 环境 问题 不 大 ， 但 还 是 强烈 建议 打开 。 
1) 创建 用 户 和 密码 : 进入 Jenkins 页 面 选择 “Manage Jenkins 一 Manage Users 一 Create User”， 填 入 用 户 名 和 密码 ， 和 动态 配置 文件 中 提 到 的 jenkins_username 和 jenkins_password 保 持 一 致 。 


2) 获取 用 户 APl token: 进入 Jenkins 页 面 选择 “Manage Jenkins 一 Manage Users 一 jenkins 用 户 一 Con-figure 一 Show API token" ， 将 获取 到 的 这 串 数 字 保 存 到 动态 数据 配置 文件 中 的 
jenkins api key 中 ，Nodepool 使 用 该 配置 参数 访问 Jenkins 的 接口 。 


3) 创建 安全 证 书 : 进入 Jenkins 页 面 选 择 “Credentials 一 System 一 Global credentials 一 Add Creden-tials" ， 类 型 选择 “SSH Username with private key”， 依 次 填写 用 户 名 “jenkins”， 私 钥 地 
HE "/var/lib/jenkins/.ssh/id rsa，” 最 后 单 击 “OK” 保存。 


Jenkins 使 用 此 证 书 来 访问 其 他 节点 。 证 书 创建 完成 后 会 产生 一 个 “uuid”， 将 该 “uuid” 保 存 到 动态 数据 配置 文件 中 的 jenkins_credentials id, 


最 后 再 运行 如 下 命令 使 新 配置 生效 。 


puppet apply /etc/puppet/manifests/site.pp 


至 此 ，5CI 系 统 搭建 完成 ， 但 是 如 何 应 用 起 来 ， 和 已 有 的 Gerrit 服 务 器 中 的 项 目 对 接 ， 还 需要 进行 项 目 配置 。 
4. 项 目 配置 


假设 Gerrit 上 已 有 openzero/sample-project 项 目 ， 以 此 为 例 介绍 下 如 何 配 置 project-conf ig 仓 库 来 管理 该 项 目的 CI 测试 。 这 里 不 再 对 该 仓库 下 的 所 有 配置 进行 详细 解释 ， 只 提供 一 个 项 目 示 例 的 最 简 
配置 。 


project-conf ig 代 码 目录 结构 如 代码 清单 10-16 所 示 : 


代码 清单 10-16 ”项 目 配置 仓库 目录 结构 


$ tree 


jenkins 
jobs 


macros.yaml 
projects.yaml 
sample-project 


sample-project.yml 
test.yaml 
views 
[一 test.yaml 
nodepool 
I— elements/ 


[- nodepool .yaml 
scripts/ 
test-requirements.txt 
tools/ 
tox.ini 
view-requirements.txt 
zuul 


layout.yaml 
openstack functions.py 


zuul.conf-sample 


首先 要 配置 Nodepool， 使 之 与 云 环境 对 接 ， 提 供 虚 机 挂 载 到 Jenkins 上 ; 然后 配置 项 目 Job， 使 用 JJB 翻 译 并 上 传 到 Jenkins 服 务 器 上 ; 最 后 ， 在 Zuu| 配 置 中 增加 该 项 目 ， 并 指定 在 什么 pipeline 下 执行 该 
Job。 


(1) Nodepool 目 录 
: elements: 镜像 编译 需要 用 到 的 elements。 
` scripts: 虚 机 起 来 之 后 ， 挂 载 到 Jenkins 之 前 需要 运行 的 一 些 测试 及 配置 脚本 。 这 两 项 可 暂 不 修改 ,采用 社区 默认 配置 。 
- nodepool.yaml: Nodepool 的 配置 文件 。 
代码 清单 10-17 是 一 个 最 简 配置 ， 其 中 providers 段 中 cloud 的 配置 必须 和 common.yaml 中 oscc f ile_contents 定 义 的 云 名称 一 致 ， 具 体 配 置 参见 第 6.4 节 。 


代码 清单 10-17 Nodepool 配 置 


elements-dir: /etc/nodepool/elements 
images-dir: /opt/nodepool dib 


cron: 
Cleanup: '*/1 * * * x! 
checks: I/I «Xxx 


zmq-publishers: 
- tcp://localhost:8888 


gearman-servers: 
- host: localhost 


zookeeper-servers: 
- host: localhost 
port: 2181 


labels: 
- name: ubuntu-trusty 
image: ubuntu-trusty 
ready-script: configure mirror.sh 
min-ready: 3 
providers: 
- name: zte-podl3-RegionOne 
providers: 

- name: zte-podl3-RegionOne 
region-name: 'RegionOne' 
cloud: zte-pod13 
api-timeout: 60 
boot-timeout: 120 
max-servers: 16 
rate: 0.001 
ipv6-preferred: false 
image-type: qcow2 
template-hostname: 'ci-book-template-(image.name)-(timestamp]' 
clean-floating-ips: true 
images: 
- name: ubuntu-trusty 

min-ram: 2048 
diskimage: ubuntu-trusty 

username: jenkins 

private-key: /home/nodepool/.ssh/id rsa 
config-drive: true 


targets: 
- name: jenkins1 
assign-via-gearman: True 
hostname: ci-book-jenkins-(label.name]-(provider.name]-(node id) 


diskimages: 

- name: ubuntu-trusty 
rebuild-age: 864000 
elements: 

- ubuntu-minimal 
- um 
- infra-package-needs 
- initialize-urandom 
- jenkins-slave 
- simple-init 
- cache-devstack 
- openstack-repos 
- nodepool-base 
- prepare-node 
- zuul-worker 
- growroot 
- stackviz 
release: trusty 
env-vars: 
TMPDIR: /opt/dib tmp 
B CHECKSUM: '1' 
B IMAGE CACHE: /opt/dib cache 


D 

D 

DIB APT LOCAL CACHE: '0' 
DIB DISABLE APT CLEANUP: '1' 
D 

D 

N 


IB GRUB TIMEOUT: '0' 
EBIAN COMPONENTS: 'main,universe' 
OOL SCRIPTDIR: /etc/nodepool/scripts 


运行 如 下 命令 使 新 配置 生效 。 


puppet apply /etc/puppet/manifests/site.pp 


Nodepool 开 始 编译 镜像 ， 这 一 步 耗 时 比较 久 ， 至 少 需 要 4 小 时 ， 完 成 后 上 传 至 云 环境 。 用 户 可 登录 云 环 境 查 看 镜像 文件 是 否 上 传 成 功 ， 如 图 10-7 所 示 ， 上 传 了 一 个 名 为 “template-ubuntu-trusty- 
1524061372” 的 镜像 ， 包 含 镜像 详细 信息 ， 以 及 Nodepool 的 定制 属性 。 


E openstack | &ouse > 
Project v 


Compute wv 


template-ubuntu-trusty-1524061372 


Overview 


Instances 


Image Security 


Volumes 


ID . cc0077e3-d20b-45e8-9157-bb27d9a2b4dd 


Type Image 
Status Active Visibility Private 


Owner  ab987d960eea4f188c899b378eb35ae7 


Access & Security Filename  - 


Network » 


Orchestration > 


镜像 上 传 成 功 之 后 ，Nodepool 使 用 该 镜像 孵化 节点 资源 池 ， 登 录 到 云 环境 上 查看 ， 如 图 10-8 所 示 ， 由 虚 机 名 称 可 以 看 出 这 些 节点 将 被 注册 到 jenkins1， 使 用 的 镜像 即 刚 上 传 的 “template-ubuntu- 


trusty-1524061372" , 


Size 

Min. Disk 

Min. RAM 

Disk Format 
Container Format 
Created At 


Updated At 


1011.06 MB Protected 
0 Checksum 
0 

QCOW2 

BARE 

2018-04-18T14:22:53Z 

2018-04-18T14:23:26Z 


Custom Properties 


direct url 


file 


Tags 
locations 


owner specified.shade.... 
nodepool upload id 
owner specified.shade.... 
nodepool build id 

Virtual Size 

owner specified.shade.... 
schema 


rbd://801bd64d-bec4-44cc-9126- 
16245e53f470/images/cc0077e3-d20b- 
45e8-9157-bb27d9a2b4dd/snap 
N2/images/cc0077e3-d20b-45e8-9f57- 
bb27d9a2b4dd/file 


[("url";"rbd://801bd64d-bec4-44cc-9126- 
16245e53f470/images/cc0077e3-d20b- 

45e8-9157- 

bb27d9a2b4dd/snap","metadata":())] 
bb304a6aba44aacb0d98b50fdf3b2840c24ede1ac96f3c474959f7fcfd66d82c 
0000000001 

images/template-ubuntu-trusty-1524061372 

0000000035 


7137c279d40a51af337663169fd9dbcc 
N2/schemas/image 


图 10-7 镜像 


节点 创建 完成 后 ，Nodepool 会 自动 将 其 注册 到 Jenkins 上 ， 登 录 Jenkins 的 Web 页 面 查看 ， 如 图 10-9 所 示 。 


(2) jenkins 目 录 


主要 是 配置 项 目的 任务 。 


No 
7f37c279d40a51af337663169fd9dbcc 


Overview 


Volumes 


Images 


Access & Security 


Network 


Orchestration 


> 


> 


Project / Compute / Instances 


Instances 


| Instance Name = = | 


| Filter | €» Launch Instance 


jenkins1- 
ubuntu-tr 
usty-zte- 
pod13-R 
egionOn 

e-22251 

0 


jenkins1- 
ubuntu-tr 
usty-zte- 
pod13-R 
egionOn 

e-22250 

7 


Image 
Name 


template- B 
ubuntu- 
trusty- 
1524061372* 


template-  . 
ubuntu- 
trusty- 
1524061372* 


template- 。 
ubuntu- 
trusty- 
1524061372* 


Koy Status 


IP Address Pair 


192.168.130.17 


Floating IPs: 
172.130.0.151 


192.168.130.4 
Floating IPs: 
172.130.0.148 


192.168.130.20 


Floating IPs: 
172.130.0.162 


EK10-8 Æp 


Availability 
Zone 


Task 


Power 
State 


B Delete Instances 


15 hours, 


Running 33m 


jenkins1-ubuntu-trusty-zte-pod13- 
RegionOne-222507 


1 Idle 


jenkins1-ubuntu-trusty-zte-pod13- 
RegionOne-222510 


1 Idle 


&& jenkins1-ubuntu-trusty-zte-pod13- 
RegionOne-222513 


1 Idle 


图 10-9 EPER 
修改 jobs 目 录 下 的 test.yaml 文 件 ， 如 代码 清单 10-18 所 示 定 义 项 目的 任务 。 


代码 清单 10-18 项 目 任 务 定义 


- job-template: 
name: 'ín 


使 用 JJB 翻 译 该 任务 定义 即 可 生成 名 为 sample-project-verify 的 任务 ， 并 上 传 到 Jenkins 服 务 器 上 。 登 录 到 Jenkins 服 务 器 上 查看 该 Job 信 息 ， 如 图 10-10 所 示 。 


€ > CC |© opnfvzte.comcn/jenkins/job/sample-project-verify/ 


£ Jenkins 


Jenkins  »  sample-project-verify — » 


g— Project sample-project-verify 


Q, Status 
«p»«b»?This job is managed by puppet and will be overwritten.«/b»«/p» 


BA Changes 


m «p»«b»Do not edit this job through the web«/b»«/p» 
(9) Storable configs 


«p»lIf you would like to make changes to this job, please see: 


Build Time Blame Report «a href-"http://opnfv.zte.com.cn/gerrit/openzero/releng"» 
http://opnfv.zte.com.cn/gerrit/openzero/releng 
</a> 


入 All Changes 


E Build Graph 
In jenkins/jobs 


e Open Blue Ocean «Ip» 
<!-- Managed by Jenkins Job Builder --> 


i» Build History 
Recent Changes 


find 


图 10-10  sample-ptoject-vetity 
(3) zuul 目 录 
任务 定义 完成 之 后 即 可 在 Zuul 的 layout.yaml 文 件 中 定义 该 项 目 在 什么 pipeline 下 运行 该 任务 。 如 代码 清单 10-19 所 示 。 


代码 清单 10-19 ”项目 引用 任务 


projects: 
- name: openzero/sample-project 
check: 


- sample-project-verify 
gate: 
- sample-project-verify 


推送 至 远程 project-config 仓 库 ， 最 后 再 运行 如 下 命令 使 新 配置 生效 。 


puppet apply /etc/puppet/manifests/site.pp 


fé. 


此 时 就 可 以 在 Gerrit 的 该 项 目下 提交 一 个 变更 ， 查 看 整个 CI 流程 是 否 工 作 正常 ， 如 图 10-11 所 示 ， 可 以 看 到 提交 了 一 个 新 变更 即 触 发 了 CI 流程 ， 测 试 通过 后 向 Gerrit 返 回 Verified+1， 整 个 流程 工作 正 


(€) > C Ù Q, gerrit.oz/#/c/2901/ || Q search | IN ee (D 


(8 You must log in to this network before you can access the Internet. | Open Network Login Page | x 


Al My Projects People Documentation | Search term 


Changes Drafts Draft Comments Edits Watched Changes Starred Changes X Groups 


Change 2301 - Needs Code-Review Label , Reply. Patch Sets (1/)) Y DownloadW = 
test for ci Owner E 5800101742 
Change-Id: I03f69172e3109864b45895bele2c78917a206051 Reviewers openzeroci x & 


Signed-off-by: dongwenjuan «dong.wenjuanGzte.com.cn : j 
3 y niuis cde ] @ z Project — openzero/sample-project E 


Branch master 

Topic lac] 
Strategy Merge if Necessary 

Updated 13 seconds ago 


| Cherry Pick Rebase || Abandon | 


Author dongwenjuan «dong.wenjuan(gzte.com.cn^ May 24, 2018 11:48 AM Code-Review 
Committer dongwenjuan «dong.wenjuan(2zte.com.cn» May 24, 2018 11:48 AM Verified *l openzeroci x 
Commit 3804blb7acaü0bf5f5835fa34dc5364f088c62dba (gitweb) 
Parent(s) ^ 46ccea88ec0e98a3fe2bdfd8cf0b22976544303b (gitweb) 
Change-Id  103f69172e3109864b45895be1e2c78917a20e051 
Files OpenAll | Diffagainst Base f| Edit - 
File Path Comments Size 


" C] CommitMessage 
( )A test 1 NENNEN 
*1,-0 ESE 
History Expand All | 
8 x5 00101742 Uploaded patch set 1. 
openzeroci 
Patch Set 1: Verified 
Build succeeded (check pipeline). 


* sample-project-verify SUCCESS in 11s 


图 10-11 CI 流程 验证 


[1] https://git.openstack.org/openstack-infra/puppet-openstackci o 


10.3 STRME 


单机 部 署 的 搭建 和 配置 相对 简单 快速 ， 但 是 不 太 适 用 于 生产 环境 ， 原 因 如 下 : 
- 组 件 都 运行 在 同一 台 服 务 器 上 ， 资 源 需 求 较 大 ， 特 别 是 Nodepool 镜 像 制 作 会 消耗 大 量 的 CPU 和 磁盘 空间 ， 这 势必 会 影响 其 他 组 件 的 运行 。 
* 不 利于 单个 组 件 的 升级 和 维护 ， 比 如 两 个 组 件 具有 相同 的 依赖 包 ， 因 为 升级 导致 版 本 不 兼容 。 


为 了 解决 上 述 问题 ， 考 虑 按 组 件 服务 拆 分 进行 多 节点 的 部 署 ， 多 节点 是 HA 部 署 的 前 提 。 以 功能 为 单位 将 单 节点 划分 为 多 个 独立 的 逻辑 节点 ， 使 用 Puppet Master/Agent 模 式 ， 功 能 节点 作为 Puppet 
Agent， 增 加 Puppet Master 节 点 作为 配置 的 中 心 。Master 和 Agent 都 是 工作 负载 节点 ， 为 了 能 部 署 这 些 服务 并 进行 有 效 管理 ， 还 需要 一 个 部 署 服务 器 运行 部 署 肢 本， 如 本 节 后 面 提 到 的 Ansible 自 动 化 部 署 
脚本 就 是 运行 在 独立 的 部 署 服务 器 上 的 ， 如 图 10-12 所 示 。 


Nodepool 
Node 


Master Node || Gerrit Node Zuul Node Jenkins Node Logserver ELK Node 


l Zuul Server Nodepool Jenkins 
Gerrit Log server 


Nodepool- 


Puppet 
Master 


Gearman 


Zuul Merger 


| JJB 
Server builder 
Puppet Agent|| Puppet Agent|| | Puppet Agent| |Puppet Agent Puppet Agenti [Puppet Agent 


Puppet Agent 


E1032 ”多 节点 CI/CD 


: Gerrit Node: 部 署 Gettit 服 务 。 

. Zuul Node: 部 署 Zuul 服 务 。 在 负荷 不 是 很 高 的 情况 下 ， 将 Zuul Server 和 Zuul Merget 部 署 在 一 个 节点 上 ; 如 果 负 荷 较 高 ， 可 以 分 开 部 署 。 

: Jenkins Node: 部 团 Jenkins 服 务 。 理 论 上 ，JJB 不 要 求 一 定 和 Jenkins 绑 定 在 一 起 ， 只 要 能 访问 Jenkins 即 可 ， 但 为 简化 复杂 度 ， 推 荐 Jenkins 和 J 有 e 一 起 部 署 。 

. Nodepool Node: 部 署 Nodepool 服 务 。 如 果 需 要 管理 的 镜像 和 VM 比 较 多 ， 可 以 将 Nodepoold 和 Nodepool-buildet 分 开 部 署 。 

: Common Node: 部 署 公共 组 件 服务 ， 如 MySQL、Zookeepetr 和 Gearman 等 。 同 样 ， 如 果 有 必要 ， 也 可 以 部 署 多 个 Common Node， 将 各 服务 部 署 在 不 同 的 节点 上 。 
: LogSetver Node: 部 署 日 志 服务 ， 收 集 任务 构建 日 志和 组 件 运行 日 志 。 

: ELK Node: 部 署 日 志 分 析 相 关 服 务 ， 包 括 Log pusher, Logstash Indexer、Elasticsearch 和 Kibana 等 ， 部 署 时 可 以 根据 实际 负荷 将 这 四 个 组 件 部 署 在 一 起 或 者 分 开 。 


需要 说 明 的 是 ， 这 些 节点 都 是 按 逻 辑 划 分 的 ， 具 体 部 署 时 可 以 根据 实际 情况 拆 分 或 合并 。 


10.3.1 laC 


本 次 部 署 每 个 组 件 之 间 没 有 使 用 HA， 用 户 如 果 想 实践 ， 只 需 增 加 对 应 的 节点 即 可 。 准 备 8 个 ubuntu 14.04 的 虚 机 ， 规 格 : 8 核 8G 内 存 80G 磁 盘 ， 一 台 作 为 Puppet Master， 其 他 作为 Puppet Agent, 


分 别 部 署 Gerrit、Zuul、Jenkins、Nodepool、 公 共 组 件 、 日 志 服 务 器 和 ELK。 其 中 日 志 服 务 器 和 ELK 服 务 器 的 磁盘 空间 可 以 相对 大 些 。 


本 次 部 署 遵守 基础 架构 即 代 码 (laC) 的 原则 ， 所 有 的 配置 和 部 署 脚本 都 代码 化 ， 放 在 system-conf ig 库 中 ， 代 码 结构 如 代码 清单 10-20 所 示 。 


代码 清单 10-20 system-config 代 码 结构 


$ tree 


hiera 
common. yaml 
hiera.yaml 
install modules.sh 
install puppet.sh 
manifests 
site.pp 
modules 
L— cibook project 
files/ 
lib 
manifests/ 
README 
templates/ 
modules.env 
README .md 
setup.cfg 
setup.py 
test-requirements.txt 
tools/ 
tox.ini 


: hiera 目 录 : common.yaml 和 hieta.yaml， 动 态 配 置 数据 和 Hieta 配 置 文件 。 
- manifests A K: 节点 配置 文件 site.pp。 
: modules 目 录 : cibook_project 模 块 ， 管 理 整 个 基础 设施 ， 部 署 组 件 的 入 口 模块 。 


: tools 目 录 : 自动 化 部 署 脚本 。 


10.3.2 配置 


鉴于 单 节点 部 署 小 节 已 经 详细 介绍 了 各 配置 文件 和 参数 说 明 ， 这 里 不 再 重复 解释 ， 只 介绍 下 不 同 之 处 。 


1. 动 态 配置 文件 hiera/common.yaml 


多 节点 的 动态 配置 如 代码 清单 10-21 所 示 。 


代码 清单 10-21 多 节点 动态 配置 文件 


I 


# See parameter documentation inside http://www.hzcourse.com/resource/readBook?path-/openresources/teach ebook/uncompressed/17933/OEBPS/Text/../manifests/single node ci.pp 
# Fields commented out have reasonable default values 


fproject config repo: 
project config repo: http://opnfv.zte.com.cn/gerrit/infra/project-config 


#vhost name: 


vhost name master: master.cibook.oz 

vhost name gerrit: &vhost name gerrit gerrit.cibook.oz 
vhost name zuul: zuul.cibook.oz 

vhost name jenkins: jenkins.cibook.oz 
vhost name nodepool: | nodepool.cibook.oz 

vhost name mysql: mysql.cibook.oz 

vhost name zookeeper:  zookeeper.cibook.oz 

vhost name gearman: &vhost name gearman gearman.cibook.oz 
vhost name log server: &vhost name log server log.cibook.oz 
vhost name elk: elk.cibook.oz 

tserveradmin: 


jenkins username: cibook 

jenkins password: cibook 

jenkins ssh private key: &jenkins ssh private key | 
----- BEGIN RSA PRIVATE KEY----- E 

二 二 二 一 一 END RSA PRIVATE KEY----- 


jenkins ssh public key: &jenkins ssh public key 

jjb git revision: 1.6.2 IL 

jjb git url: https://git.openstack.org/openstack-infra/jenkins-job-builder 
gearman server: *vhost name gearman 
gerrit server: *vhost name gerrit 
gerrit user: cibook 

gerrit user ssh private key: *jenkins ssh private key 
gerrit user ssh public key:  *jenkins ssh public key 
gerrit user http passwd: cibook EM i 
gerrit ssh host key: 

git email: cibookG8zte.com.cn 


git name: cibook 


log server: *vhost name log server 
log server public: *vhost name log server 
#smtp host: 

#smtp default from: 

#smtp default to: 


zuul revision: 2.5.2 
zuul git source repo: https://git.openstack.org/openstack-infra/zuul 


oscc file contents: | 
4 Do Not Edit - Generated & Managed by Puppet 
# 
# Insert OSCC file contents here as explained in the 
# documentation so that nodepool is able to 
# authenticate to your cloud(s) 
client: 
force ipv4: true 
clouds: 
zte-podl3: 
profile: internap 
floating ip source: 'neutron' 
auth: = 
username: 'cibook' 
password: 'cibook' 
project name: 'cibook' 
auth url: 'http://hl13.02:5000/v2.0" 
regions: 
- name: RegionOne 
values: 
networks: 
- name: admin floating net 
routes externally: true 
- name: net-ci 
nat destination: true 
default interface: true 


#nodepool mysql db config: 
mysql bind address: '0.0.0.0' 
ysql root password: root123 
ysql nodepool db name: nodepool 
ysql nodepool password: root123 


-ECN- 


#gerrit mysql db config: 

mysql gerrit root password: UNSET 
mysql gerrit name: reviewdb 

mysql gerrit user: gerrit2 

mysql gerrit password: 12345 


nodepool jenkins target: jenkins-cibook 
jenkins api key: 31a5ae595bab5ce364df264bac70e54c0 
# jenkins api key get from, !Jenkins 
jenkins credentials id: 9c72e2be-25c9-4233-a2ac-4d4c8664312a4 
# jenkins,!credentials id get from Jenkins 


nodepool revision: 0.4.0 
nodepool git source repo: https://git.openstack.org/openstack-infra/nodepool 


domain: cibook.oz 


*swift authurl: 

swift user: 

#swift key: 

#swift tenant name: 
#swift region name: 
*swift default container: 


对 于 单机 部 署 ， 因 为 只 有 一 台 服 务 器 ， 所 以 只 需要 一 个 vhost name 配置 ; 对 于 多 节点 部 署 ， 需 要 配置 各 节点 的 主机 名 ， 新 增 各 节点 的 主机 名 参数 vhost name (component), ErR(component)BDzs 
组 件 名 。 


日 志 服 务 器 的 配置 数据 也 放 入 该 动态 配置 文件 中 。 

同时 新 增 Gerrit 服 务 部 署 的 配置 数据 如 下 : 
: mysql gerrit root password: 数据 库 的 root 用 户 密码 ， 用 来 登录 数据 库 创建 Gerrit 用 户 。 
: mysql gerrit name: Gettit 的 数据 库 名 。 
- mysql. gerit, userfemysql. gerrit password: Gertit 访 问 mysql 的 用 户 名 和 密码 。 

其 他 的 配置 可 参考 单机 部 署 相关 介绍 。 

2. 节 点 配置 文件 manifests/site.pp 


所 有 待 部 署 节点 的 配置 都 放 入 该 文件 下 ， 节 点 配置 如 代码 清单 10-22 所 示 。 


代码 清单 10-22 ”多 节点 节点 配置 文件 


node 'gerrit.cibook.oz' ( 


$vhost name gerrit = hiera('vhost name gerrit', $::fqdn) 
package ( 'ssl-cert': 
nsure => present, 
} 
xec { 'ensure group ssl-cert exists': 
command => '/usr/sbin/groupadd -f ssl-cert' 


} 


# workaround since pip 


is not being installed as part of this module 


package ( 'python-pip': 
nsure => present, 

} 

class { 'gerrit': 
mysql host => hiera('vhost name mysql'), 
mysql password => hiera('mysql gerrit password'), 
vhost name => $vhost name gerrit, 
redirect to canonicalweburl => false, 
canonicalweburl => "https://S$[(vhost name gerrit]", 
war => 


errit/gerrit-v2.9.4.5.73392ca.war', 
gerrit auth type 
manage jeepyb 


} 
} 


=> 'DEVELOPMENT BECOME ANY ACCOUNT', 
false, 


=> 


'http://tarballs.openstack.org/ci/g- 


node 'jenkins.cibook.oz' 


{ 


$vhost name jenkins = hiera('vhost name jenkins', $: 
class ( '::cibook project::jenkins node': 
vhost name => $vhost name jenkins, 
project config repo => hiera('project config repo'), 


: fgdn) 


name je 


stack.org/openstack-in! 
java args overrid 


serveradmin => hiera('serveradmin', "webmaster@$ {vhost | 


nkins}"), 


jenkins version 
enkins vhost nam 


=> hiera('jenkins version', 'present'), 


=> hiera('jenkins vhost name', 'jenkins'), 


Og server 


TCI. H| U- U- U- U- U- C 


jjb git url 


enkins usernam 
enkins password 
enkins ssh private key 
enkins ssh public key 


jb git revision 


=> hiera('jenkins username', 'jenkins'), 
=> hiera('jenkins password', 'XXX'), 


=> hiera('jenkins ssh private key'), 
=> hiera('jenkins ssh public key'), 


=> hiera('log server'), 


=> 


fra/jenkins-job-builder'), 


=> hiera('jjb git revision', '1.6.2'), 
hiera('jjb git url',https://git.open- 


=> hiera('java args override', '-Dh- 


udson.model.ParametersAction.keepUndefinedParameters-true -Dorg.apache.commons.jelly.tags.! 


} 
} 


node 'log.cibook.oz' { 
class ( '::cibook project::logserver node': 


} 


node 


domain => hiera('domain'), 

jenkins ssh key => hiera('jenkins ssh public key'), 
swift authurl => hiera('swift authurl', ''), 

swift user => hiera('swift user', '!'), 

swift key => hiera('swift key', ''), 

swift tenant name => hiera('swift tenant name', ''), 
swift region name -» hiera('swift region name', ''), 
swift default container => hiera('swift default container', 


'zuul.cibook.oz' { 
$vhost name zuul = hiera('vhost name zuul', $: 


: fqdn) 


class ( '::cibook project::zuul node': 


$(vhost name zuul)"), 


vhost name => $vhost name zuul, 

project config repo => hiera('project config repo'), 
gearman server => hiera('gearman server'), 

gerrit server => hiera('gerrit server'), 

gerrit user => hiera('gerrit user'), 
gerrit user http passwd => hiera('gerrit user http passwd'), 
gerrit user ssh public key 
gerrit user ssh private key 
gerrit ssh host key 
git email | 
git name 
log server 
log server public 
smtp host 
smtp default 


-» hiera('gerrit user ssh privat 
=> hiera('gerrit ssh host key'), 
-=> hiera('git email'),  . g 
=> hiera ('git name'), 
=> hiera('log_server'), 
=> hiera('log server public'), 
=> hiera('smtp host', 'I 


localhost'), 
From => hiera('smtp default from', 


"zuulG- 


smtp default to => hiera('smtp default to', "zuul.report 
@$ {vhost name zuul])"), 
zuul revision => hiera('zuul revision', 'master'), 


} 


zuul git source repo 


=> hiera('zuul git source repo'), 


node 'nodepool.cibook.oz' { 


che 


$vhost name nodepool = hiera('vhost name nodepool', $: 


fqdn is not resolvable, use its ip address 


: fgdn) 


class ( '::cibook project::nodepool node': 


pool'), 


vhost name => $vhost name nodepool, 

project config repo => hiera('project config repo'), 
jenkins usernam => hiera('jenkins username', 'jenkins'), 
jenkins ssh public key => hiera('jenkins ssh public key' 
jenkins ssh private key => hiera('jenkins ssh private key' 
oscc file contents => hiera('oscc file contents', ''), 
mysql host => hiera('vhost name mysql'), 

mysql root password => hiera('mysql root password'), 
mysql db name => hiera('mysql nodepool db name', 'node- 


); 
); 


mysql nodepool password => hiera('mysql nodepool password'), 
nodepool jenkins target => hiera('nodepool jenkins target', 
jenkins api key => hiera('jenkins api key', 'XXX'), 
jenkins credentials id => hiera('jenkins credentials id', 
jenkins url -» hiera('jenkins url', 'http://jenkins- 


Pty 


=> hiera('gerrit user ssh public key'), 


e key'), 


s- 


'jenkins-cibook'), 


'XXX'), 


.cibook.oz:8080'), 
nodepool revision => hiera('nodepool revision', 'master'), 
nodepool git source repo => hiera('nodepool git source repo',- 


http: //opnfv.zte.com.cn/gerrit/openstack/nodepool'), 
} 


} 


node 'elk.cibook.oz' { 


S$elasticsearch nodes 


zn 


hiera('vhost name elk') ] 


class ( 'cibook project::logstash': 


} 


discover nodes => [ "hiera('vhost name elk'):9200" ] 


class ( 'cibook project::logstash worker': 


discover node 
enable mqtt 


=> hiera('vhost name elk'), 


=> false, 


mqtt hostname 
mqtt password Ew t. 
mqtt ca cert contents 


=> ! 


=> hiera('vhost name elk'), 


Y 
, 


tmt.timeZone-Asia/Shanghai') # lint:ignore:140chars 


class ( 'cibook project::elasticsearch node': 
discover nodes => $elasticsearch nodes 


} 
J 


node 'gearman.cibook.oz' { 
class { 'gearman': } 


} 


node 'zookeeper.cibook.oz' { 
class ( '::cibook project::common nodepool db': 
vhost name => hiera('vhost name zookeeper', $::-fqdn), 
mysql bind address => hiera('mysql bind address'), 
mysql root password => hiera('mysql root password'), 
mysql nodepool password => hiera('mysql nodepool password'), 


class { 'zookeeper': 
install java-» true, 
java package => 'openjdk-7-jre-headless', 


各 节点 调用 cibook_project 模 块 中 的 类 完成 部 署 。 


3. 部 署 模块 modules/cibook_project 


openstackci 模 块 是 单机 部 署 的 入 口 模块 ， 在 single_node ci 类 中 部 署 了 Jenkins、Zuul 和 Nodepool， 对 于 多 节点 音 


管理 ， 其 他 Gerrit、ELK 和 日 志 服务 器 等 相关 资源 管理 也 放 在 此 模块 下 。 
Puppet 模 块 的 调用 关系 如 图 10-13 所 示 。 


配置 完成 之 后 ， 下 面 进行 自动 化 部 署 。 


10.33. EAE 


在 部 署 服务 器 上 使 用 Ansible 自 动 化 部 署 工具 编排 待 部 署 的 节点 : 
- 安装 和 配置 Puppet， 完 成 Agent 向 Mastet 的 自动 认证 。 
: 驱动 Puppet 自 动 化 安装 部 署 各 节点 上 的 CI 应 用 服务 。 
部 署 脚本 位 于 system-conf ig/tools 目 录 下 ， 如 代码 清单 10-23 所 示 。 


代码 清单 10-23 ansible 部 署 脚本 代码 结构 


$ tree 


ansible.cfg 
inventory 
puppetagents.yml 
puppetmaster.yml 
roles 


[一 puppet.conf.j2 
puppetmaster 
defaults 


handlers 
L— main.yml 
tasks 
main.yml 
templates 
T autosign.conf.j2 

puppet .conf.j2 

puppet-node 

tasks 

L— main.yml 


Er 


A 


mm 
Ris 


要 把 它们 按 组 件 拆 开 成 独立 的 类 ， 新 增 cibook_project 模 块 来 完成 这 些 类 的 


Common 


:gearman ::zookeeper 


openstackci:: 
:jenkins:: 
job builder 


jenkins master 


openstackci:: 


zuul scheduler -:zuul::server 
openstackci:: 
| zzuul::merger 
zuul merger 


| . NodePool 


openstackci:: 
nodepool :nodepool:: 
builder 


cibook project 


logserver 


openstackci:: 
logserver 


cibook project:: 
logstash worker 
——SmÉÓ, cibook project: 


logstash 


cibook project:: 
elasticsearch 


E1033 ”多 节点 部 署 模块 调用 关系 


各 部 署 脚本 不 做 详细 说 明 。 


首先 在 部 署 服务 器 上 安装 Ansible: 


sudo apt-add-repository -y ppa:ansible/ansible 
sudo apt-get update -y 
sudo apt-get install -y ansible 


然后 复制 system-config 库 到 部 署 服务 器 上 ， 进 入 tools 目 录 下 ， 执 行 如 下 命令 即 可 运行 部 署 : 


laybook puppetmaster.yml 
laybook puppetagents.yml 


ansibl 
ansibl 


a 
D 'O 


Ansible 内 部 部 署 流 程 如 图 10-14 所 示 。 


Deployment 


Server 


Puppet 
Master 


E1034 多 节点 自动 化 部 署 流程 
1. 所 有 待 部 署 节 点 
1) 在 所 有 待 部 署 节点 上 安装 NTP 服 务 ， 防 止 由 于 时 钟 不 同步 导致 Puppet Agent 和 Puppet Master 同 步 失败 。 
2) 修改 宿主 机 名 称 。 
2.Master 节 点 
1) 安装 puppetmaster 服 务 。 
2) 设置 自动 签名 认证 。 
3) 修改 puppet.conf 文 件 ， 重 启 puppetmaster 服 务 使 配置 生效 。 
3.Agent 节 点 
1) 安装 puppet 服 务 。 
2) 修改 puppet.conf 文 件 ， 指 定 Master 服 务 器 地 址 以 及 本 机 向 Master 认 证 的 名 称 。 
3) 使 能 puppet 服 务 。 
4.Puppet Agent 和 Puppet Master 交 互 
1) Agent 向 Master 发 送 认 证 请 求 ，Master 根 据 Agent 携 带 的 主机 名 决定 是 否认 证 签名 。 
2) 认证 签名 通过 ，Agent 携 带 主 机 名 和 facts 向 Master 请 求 catalog。 
3) Master 分 析 客 户 端的 主机 名 ， 找 到 该 主机 的 配置 代码 ， 编 译 catalog 并 发 回 客 户 端 。 
4) Agent 执 行 代码 完成 各 节点 组 件 部 署 ， 并 把 执行 情况 反馈 给 Master。 


最 后 由 用 户 根 据 执行 结果 查看 部 署 情况 ， 这 里 不 再 袭 述 。 


10.4 使 用 CI/CD 


到 目前 为 止 , 我 们 只 是 建立 了 一 个 具有 CI/CD 基 础 设施 的 框架 ,里面 没 有 任何 内 容 ， 下 面 我 们 介绍 如 何 使 用 这 个 系统 。 站 在 OpenStack CI/CD 的 角度 ， 可 以 将 用 户 分 成 以 下 几 类 : 


- Infra team， 即 CI/CD 基 础 设施 团队 。 主 要 负责 CI/CD 系 统 的 部 署 和 维护 (如 扩容 、 数 据 备份 和 迁移 等 ) ， 保 证 CI/CD 系 统 对 所 有 项 目 可 用 。Infta team 日 常 工作 也 包括 协助 项 目 团队 管理 C1/CD。 
: Project cteatot， 即 项 目 创建 者 ， 一 般 为 项 目 最 初 的 PIL (Project Team Leader) ; 
: Developer， 即 项 目的 开发 者 ， 包 括 核心 开发 者 (core member) 和 普通 开发 者 (deve-loper) ， 也 包括 PTL。 
对 CIMCD 的 使 用 可 分 为 两 个 部 分 ， 即 新 增 项 目 和 提交 变更 ， 下 面 分 别 加 以 介绍 ， 前 者 针对 Project creator 而 言 ， 后 者 包括 所 有 的 Developer。 


为 使 描述 更 有 针对 性 ， 我 们 以 文档 开发 为 例 ， 介 绍 在 前 面 搭建 的 Cl/CD 系 统 中 如 何 创建 项 目 、 如 何 提 交 变 更 ;为 了 便于 评审 和 版 本 控制 ， 我 们 使 用 rst 格 式 编 写 文档 ， 每 次 变更 都 会 触发 CI/CD 对 文档 进 
行 语法 检查 、 自 动 文档 构建 ， 并 自动 将 文档 以 html 和 和 pdf 格式 发 布 到 对 应 的 服务 器 上 。 整 个 示意 图 如 图 10-15 所 示 。 


ES ~ 
A Y M Node Y Publish 
Gerrit Eu | 
Developers Server 


E10-15 ”通过 CI/CD 进 行文 档 开发 示意 图 


10.4.1 新 增 项 目 


通常 增加 项 目 需要 考虑 以 下 几 个 步骤 : 

1) Gerrit 中 增加 项 目 并 作 相 关 配 置 。 

2) Zuul 中 配置 pipeline。 

3) Jenkins 中 增加 Jobs。 

4) Nodepool 中 增加 标签 类 型 或 镜像 。 

如 果 使 用 的 Gerrit 中 已 有 项 目 ， 也 需要 增加 相关 权限 配置 ; Nodepool 中 的 配置 项 可 以 根据 实际 需求 调整 。 

项 目 创建 一 般 由 Project creator 发 起 ， 由 Infra team 成 员 配 合 执行 (如 检查 新 加 入 的 配置 对 其 他 项 目 是 否 影响 ) 。 
Og 

如 非特 殊 说 明 ， 下 面 所 有 的 配置 都 是 修改 project_config 项 目下 的 文件 。 

地 址 为 https://github.com/openzero-team/project_config, git 

1.Gerrit 中 新 增 项 目 

待 增加 的 项 目 可 以 继承 已 经 存在 的 项 目 ,或 者 是 全 新 的 项 目 ， 不 管 哪 种 情况 ， 要 使 用 CI/CD 系 统 ， 第 一 步 需要 将 项 目 增加 到 Gerrit 中 ， 大 致 包括 以 下 几 个 步骤 : 
1) 添加 项 目 。 

2) 增加 项 目 用 户 组 。 

3) 分 配 用 户 组 权限 。 

4) 创建 /删除 项 目 分 支 。 


Gerrit 的 配置 修改 主要 涉及 gerrit/projects.yaml 文 件 和 gerrit/acls/ 文 件 夹 下 的 文件 。 前 者 是 Gerrit 所 有 项 目 及 配置 列表 ， 后 者 是 各 对 应 项 目的 权限 配置 ;对 于 配置 文件 中 不 支持 的 操作 (如 创建 项 目 分 
支 或 标签 ) ， 可 以 使 用 Gerrit CLI 或 在 Web UI 上 配置 。 


(1) 添加 项 目 
在 Gerrit 中 添加 项 目 主要 包括 两 种 情况 : 


1) 新 增 项 目 。 修 改 gerrit/projects.yaml， 在 该 文件 中 增加 项 目 定 义 ， 如 下 所 示 : 


- project: «project namespace>/<projectname> 
description: «some descriptions» 


2) 创建 既 有 项 目 。 如 果 项 目 库 已 经 存在 (如 待 加 入 的 项 目 是 基于 某 个 上 游 项 目 ) ， 有 两 种 方法 : 


: 使 用 upstream 将 项 目 导 入 ， 如 下 所 示 : 


- project: «project namespace>/<projectname> 


description: «some descriptions» 
upstream: «upstream url» 


: 首先 在 Gettit 上 创建 空 项 目 ， 然 后 从 上 游 将 对 应 的 项 目 复制 到 本 地 ， 再 push 到 Gettit 上 。 
如 果 需 要 保留 所 有 历史 ， 推 荐 使 用 upstream 字 段 导 入 的 方式 ;而 使 用 push 的 方式 可 以 只 保留 最 近 一 部 分 历史 ， 从 而 减少 空间 占用 。 用 户 可 根据 实际 情况 选择 。 
创建 空 项 目 也 可 以 通过 Gerrit 提 供 的 Web UI 直接 操作 或 者 通过 CLI， 具 体 参 见 3.2 节 中 的 描述 。 


对 于 本 文档 项 目 添加 如 下 : 


- project: openzero/openzero 
description: Configuration files for CI/CD book 


(2) 增加 项 目 用 户 组 
对 于 一 个 项 目 ， 一 般 需 要 创建 如 表 10-1 所 示 的 用 户 组 。 


表 10-1 项 目 用 户 组 
序号 用 户 组 职责 


| CETTUNETEENIT: 


2 «projectname»-manager 或 者 «projectname--release 版 本 管理 组 ， 拥 有 打 标 签 的 权限 


以 上 只 是 OpenStack 社 区 推荐 的 默认 组 ， 可 以 根据 实际 项 目 管理 的 需要 增加 其 他 的 组 ， 如 <projectname> -owner 组 描述 项 目的 所 有 者 ， 其 中 只 包含 PTL 或 少数 几 个 核心 成 员 ， 对 项 目 拥 有 最 高 的 权 
限 。 


All My Projects People X Plugins Documentation 
List Groups Create New Group 


Create Group 


Create New Group 


Create Group 


图 10-16 ”通过 Web 创 建 用 户 组 
增加 用 户 组 可 以 使 用 Web UI 方式 : 以 管理 员 的 身份 登录 Gerrit Dashboard， 通 过 People 一 Create New Group 创建 ， 如 图 10-16 所 示 。 


也 可 以 通过 CLI 的 方式 创建 : 


ssh -p 29418 <administrator>@<gerritserver> gerrit create-group «group-name» 


其 中 <administrator> 是 Gerrit 管 理 员 名 称 ，< gerritserver> 是 Gerrit 服 务 器 的 地 址 ，<group-name> 是 需要 创建 的 组 名 ， 即 <projectname> -core 或 者 <projectname>-manager 等 。 创 建 完 用 户 组 
后 ， 可 以 为 组 添加 用 户 ， 可 以 通过 Web 方 式 进 行 ， 如 图 10-17 所 示 。 


All My Projects People Plugins Documentation 
List Groups Create New Group 


Group citest-core 


General Member s 
Name or Email 
Member Email Address 
Q Administrator admin example.com 


Delete 
Included Groups 
Group Name 


Group Name 


Delete | 


为 用 户 组 添加 成 员 时 ， 除 了 直接 添加 用 户外 ， 还 可 以 引用 其 他 的 组 。 
Qu 


添加 到 组 中 的 用 户 必须 是 已 经 在 Gerrit 中 注册 的 用 户 。 


图 10-17 为 组 添加 用 户 


为 openzero 添 加 的 用 户 组 如 图 10-18 所 示 。 


All My Projects People Plugins Documentation Search term 
List Groups Create New Group 


Groups 


g SEE 
Group Name Description 
Administrators Gerrit Site Administrators 
Non-Interactive Users Users who perform batch actions on Gerrit 
openzero-core 


openzero-manager 
Powered by Gerrit Code Review (2.13.11) | Press '?' to view keyboard shortcuts 


图 10-18  opnezero group 
openzero 项 目 添 加 了 openzero-core 和 openzero-manager 两 个 用 户 组 。 
为 openzero 添 加 的 用 户 如 图 10-19 所 示 。 


All My Projects People Plugins Documentation eg ee | Changes $ search Administrator ~ 
List Groups Create New Group 


Group openzero-core 


Members 
Name or Email 
Member 
O dongwenjuan 
( julien 
口 shangxdy 
Delete | 
Included Groups 
Group Name 


Group Name 


Delete | 
Powered by Gerrit Code Review (2.13.11) | Press '?' to view keyboard shortcuts 


图 10-19  opnezero members 


(3) 添加 项 目 权限 


Gerrit 权 限 都 是 基于 用 户 组 的 ， 一 旦 为 用 户 组 赋予 了 某 种 权限 ， 该 组 中 所 有 的 用 户 都 将 具有 对 应 的 权限 ; 关于 项 目 权限 可 以 参见 3.2 节 中 的 摘 述 。 对 于 指定 的 项 目 权限 配置 ， 需 在 项 目下 增加 文件 
gerrit/acls/openzero/openzero.config， 如 代码 清单 10-24 所 示 : 


代码 清单 10-24 openzero 项 目 权 限 配置 


[access "refs/heads/*"] 
abandon = group openzero-core 
create = group openzero-manager 


label-Code-Review = -lhttp://www.hzcourse.com/resource/readBook?path-/openresources/teach ebook/uncompressed/17933/OEBPS/Text/..*1 group Registered Users 
label-Code-Review = -2http://www.hzcourse.com/resource/readBook?path-/openresources/teach ebook/uncompressed/17933/OEBPS/Text/..*2 group openzero-core 
label-Workflow = -1http://www.hzcourse.com/resource/readl 


Book?path-/openresources/teach ebook/uncompressed/17933/OEBPS/Text/..*1 group openzero-core 


[access "refs/tags/*"] 
pushSignedTag = group openzero-manager 


[receive] 
requireChangeId = tru 
requireContributorAgreement = true 


[submit] 
mergeContent = true 


配置 中 人 允许 核心 成 员 和 版 本 管理 员 创 建 分 支 ， 但 是 只 人 允许 版 本 管理 员 创 建 标签 ;核心 成 员 可 以 废弃 某 个 提交 ， 


普通 开发 者 有 -1/+1 的 权限 ， 但 是 核心 成 员 有 -2/+2 和 执行 workflow 的 权限 ; 另外 从 配置 
中 还 可 以 看 出 ， 开 发 者 需要 签署 许可 协议 才能 在 本 项 目 中 提交 变更 ， 且 提交 变更 需要 Changeld。 
除了 通过 配置 文件 修改 权限 外 ， 还 可 以 通过 Web UI 进 行 修改 ， 具 体 修改 路 径 为 Projects 一 Access。 


(4) 增加 /删除 项 目 分 支 


项 目 默认 当前 的 分 支 为 master 分 支 ， 可 能 会 根据 情况 创建 其 他 分 支 ， 如 dev。 不 能 通过 配置 文件 为 项 目 增加 或 删除 分 支 ， 需 要 通过 CLI 或 者 Gerrit Web UI 进行 操作 ， 上 有 具体 参 见 3.2 节 中 的 描述 。 


2. 在 Zuul 中 配置 pipeline 


完成 了 新 项 目 在 Gerrit 中 的 配置 ， 接 下 来 需要 在 Zuul 中 为 项 目 定义 pipeline 规 则 了 : 选择 或 新 定义 项 目 需要 的 pipeline， 并 说 明 项 目 在 该 pipeline 需 要 执行 哪些 Job。 
Zuul pipeline 的 配置 位 于 zuulylayout.yaml 中 ， 该 文件 包括 以 下 几 个 部 分 : 

. bipelines 配 置 。 

- project-templates 配 置 。 

` jobs 配 置 。 


projects 配 置 。 
其 中 前 三 个 配置 都 是 为 第 四 个 projects 配 置 服务 的 ， 且 必须 对 pipelines 和 projects 进 行 配置 ，project-templates 和 jobs 两 部 分 可 以 根据 实际 情况 选择 配置 。 
(1) 配置 pipelines 


该 过 程 主要 是 为 项 目 选 择 合适 的 工作 流 ， 工 作 流 由 一 系列 pipeline 组 成 ，OpenStack CI/CD 提 供 了 一 些 通 用 的 pipelinel1]， 可 以 将 这 些 定义 复制 过 来 直接 使 用 ， 本 节 不 对 这 些 pipeline 定 义 作 详 细 解 释 ， 
MU NEA UE 


- check: 新 的 变更 提交 后 ， 会 进入 此 pipeline， 运 行 对 应 项 目 在 此 pipeline 下 的 Job 后 ， 根 据 测 试 结 果 ， 自 动 给 出 +1/-1 的 评价 ; 该 pipeline 一 般 用 来 进行 代码 静态 检查 、 单 元 测试 等 。 
: gate: 变更 被 核心 成 员 批准 后 会 进入 此 pipeline， 如 果 项 目 在 该 pipeline 下 的 Job 都 运行 成 功 ， 变 更 会 被 合 入 目标 分 支 ; 该 pipeline 一 般 用 来 进行 集成 测试 。 

| post: 合 入 目标 分 支 后 的 变更 会 进入 该 pipeline， 该 pipeline 一 般 用 来 发 布 临 时 文档 或 软件 ， 或 者 用 来 将 变更 部 署 到 非 正式 环境 (如 测试 环境 ) Po 

: pre-release: 项 目 打 上 预 发 布 标 签 ( 标 签名 称 以 “rc” 结 尾 ) 后 ， 会 进入 该 pipeline; 一 般 使 用 该 pipeline 来 处 理 项 目 版 本 预 发 布 ， 如 推送 预 商用 版 本 到 制品 库 ， 或 者 将 版 本 部 署 到 预 商 用 环境 。 
release: 项 目 打上 发 布 标签 (标签 名 称 不 以 tc ”结尾 ) 后 ， 会 进入 该 pipeline; 一 般 使 用 该 pipeline 来 处 理 版 本 正式 发 布 ， 如 推送 正式 版 本 到 制品 库 ， 或 者 在 正式 环境 中 部 署 项 目 。 
silent: 该 pipeline 一 般 用 于 测试 Job， 只 有 测试 无 误 后 才 允 许 进入 experimental pipeline; 变更 需要 手动 触发 才能 进入 该 pipeline。 

: experimental: 该 pipeline 一 般 用 于 测试 Job， 测 试 通过 后 才 人 允许 进 入 check pipeline; 


变更 需要 手动 触发 才能 进入 该 pipeline。 


: periodic: 周期 性 触发 的 pipeline， 对 于 需要 周期 性 运行 Job 的 项 目 ， 可 以 使 用 该 pipeline; 该 pipeline 和 具体 变更 无 关 ，Job 是 由 设 定 的 时 间 周 期 性 触发 的 ， 如 每 天 编译 版 本 或 每 隔 一 段 时 间 运 行 一 次 测试 任 


x 


通过 这 些 pipeline 可 以 为 项 目 组 织 工 作法 ， 典 型 的 工作 流 如 下 : 

check 一 gate 一 post 一 pre-release 一 release。 

Qiu 

为 项 目 新 增 Job 时 ， 如 果 不 确定 Job 是 否 可 以 稳定 运行 ， 社 区 推荐 的 做 法 是 : 

默认 使 用 silent pipeline， 通 过 增加 recheck silent 或 revetify silent 评 论 手动 触发 Job 运 行 

. 如 果 silent 下 Job 运 行 都 成 功 ， 将 Job 移 动 到 expetimental pipeline 下 ， 通 过 增加 check expetimental 评 论 手动 触发 Job 运 行 

. 如 果 expetimental 下 Job 运 行 也 成 功 ， 则 意味 着 可 以 将 Job 移 动 到 check pipeline， 且 Job 配 置 为 non-voting 模 式 ， 然 后 通过 变更 自动 触发 Job， 并 分 析 其 结 
只 有 check pipeline 运 行 成 功 后 ， 再 增加 gate pipeline， 并 将 Job 配 置 为 voting 模 式 。 


如 果 上 面 提供 的 pipeline 不 能 满足 项 目的 要 求 ， 可 以 根据 需要 自 定 义 pipeline。 我 们 假设 下 面 的 一 个 场景 : 变更 合 入 到 目标 分 支 后 ， 会 触发 新 的 部 署 ， 但 有 时 可 能 部 署 会 失败 ， 且 失败 不 是 因为 变更 导致 
的 (如 偶尔 网 络 的 问题 ) ， 按 照 一 般 的 pipeline 流 程 ， 为 了 定位 这 类 部 署 失败 的 真正 原因 ， 需 要 按照 check 一 gate 一 post 工 作 流程 依次 触发 所 有 Job 的 执行 ， 这 个 过 程 可 能 会 比较 久 ， 有 时 也 没有 必要 ， 为 了 
解决 这 类 问题 ， 我 们 在 post 后 定义 一 个 新 的 pipeline， 支 持 手动 触发 软件 部 署 ， 即 整个 pipeline 流 程 变 为 check 一 gate 一 post|redeploy。pipeline 的 前 后 变化 如 图 10-20 所 示 。 


Metri 修改 后 


图 10-20 ”通过 pipeline 改 变 工作 流 


为 openzero 新 加 入 的 pipeline 定 义 如 代码 清单 10-25 所 示 : 


代码 清单 10-25 ”定义 新 的 pipeline-redeploy 


redeploy 


- name: redeploy 
description: » 
Have a change to redeploy the patchset when deployment procedure runs wrong. 


manager: 


ignore-dependencies: true 


Source: 


gerrit 


precedence: low 
require: 
approval: 


— verified 


open: false 


trigger: 


gerrit: 


failure-message: Deployment failed (redeploy pipeline). 
IndependentPipelineManager 


[1, 2] 


— event: comment-added 


comment: 
forecedeploy) 


(?i)^ (Patch Set [0-9]4:) ? ( [NwNN*-] *) * (AnNn) ?\s* (redeploy| 


这 样 ， 如 果 一 个 项 目 使 用 了 redeploy pipeline， 在 新 的 变更 合 入 后 ， 对 于 出 现 自动 部 署 失 败 的 情况 ， 只 需要 在 变更 中 增加 redeploy 或 者 forcedeploy 的 评论 ， 就 会 重新 触发 部 署 流程 。 


(2) 配置 project-templates 


项 目 模 板 的 定义 位 于 project-templates: 中 。 配 置 project-templates 包 括 直 接 在 新 增 项 目 中 引用 已 有 的 模板 定义 ， 也 包括 定义 新 的 模板 。 代 码 清单 10-26 是 为 0openzero 定 义 项 目 模 板 。 


代码 清单 10-26 openzero 项 目 模 板 


project-templates: 
- name: book-rst-jobs 


check: 
- '(name]-docbuild-rst' 
gate: 
- '(name]-docbuild-rst' 
post: 
- '(name]-docbuild-rst-release' 


新 定义 的 模板 名 称 为 book-rst-jobs，, 使 用 了 check、gate 和 post 三 个 pipeline， 其 中 前 两 个 pipeline 完 成 文档 的 检查 和 编译 ， 最 后 一 个 完成 文档 的 发 布 。 


(3) 配置 projects 


有 了 pipeline， 定 义 好 了 project-templates， 就 可 以 在 项 目 中 定义 需要 运行 哪些 job 了 。 project 的 配置 在 projects: 中 。 有 两 种 方式 定义 项 目 中 的 Job ， 一 是 通过 template 引 用 project-templates 中 的 定 
义 ， 另 一 种 是 直接 在 项 目 中 定义 指定 pipeline 下 的 Job 列 表 。 如 代码 清单 10-27 所 示 。 


代码 清单 10-27 为 openzero 定 义 projects 


- name: openzero/openzero 
template: 

- name: book-rst-jobs 
redeploy: 

' (name) -docbuild-rst-release' 


代码 清单 10-27 中 通过 模板 引用 了 project-templates 中 的 模板 定义 即 book-rst-jobs,， 


代码 清单 10-28 ”展开 后 的 projects 


- name: openzero/openzero 


并 且 为 redeploy pipeline 增 加 了 Job{name}-docbuild-rst-release， 这 个 定义 和 代码 清单 10-28 中 的 定义 是 一 个 效 


check: 
- '(name]-docbuild-rst' 
gate: 
- '(name]-docbuild-rst' 
post: 
- '(namej)-docbuild-rst-release' 
redeploy: 
- '(namej])-docbuild-rst-release' 
Qus 


Zuul 中 定义 的 只 是 Job 和 触发 条 件 ， 而 不 定义 Job 的 具体 执行 行为 ，Job 的 具体 行为 是 在 Jenkins 中 定义 的 。 


(4) 配置 Jobs 


Jobs 的 配置 位 于 jobs 中 ， 主 要 对 用 户 运 行 Job 的 属性 做 一 些 调 整 ， 如 Job 的 运行 结果 是 人 否 参与 投票 ，Job 只 关心 项 目下 某 些 文件 的 变更 ， 或 者 指定 Job 只 运行 在 特 
为 execute-jenkins-view-apply-in-cimaster 的 Job 时 ， 不 需要 根据 运行 结果 进行 投票 : 


- name: execute-jenkins-view-apply-in-cimaster 


voting: 


false 


r3 


AE 


的 分 支 下 等 。 如 下 代码 定义 了 运行 名 称 


Qu 


不 投票 的 配置 建议 只 在 拥有 check pipeline 的 Job 中 增加 ， 不 应 该 为 gate 下 的 Job 增 加 该 属性 ， 因 为 在 gate 中 增加 这 样 的 Job 是 一 种 资源 的 浪费 。 


代码 清单 10-29 是 为 openzero 定 义 的 Job 过 滤 规 则 。 如 果 openzero 项 目 中 docs 目 录 或 doc 目 录 下 的 文件 变化 ，opezero-docbuild-rst 和 opezero-docbuild-rst-release 两 个 Job 会 触发 运行 ， 但 会 忽略 
docs/cor/ 目 录 下 的 文件 的 变化 ， 并 且 项 目 根 目录 下 rst 后 缀 的 文件 发 生变 化 也 会 触发 这 两 个 Job 运 行 。 


代码 清单 10-29 openzero Job 过 滤 规 则 


jobs: 

- name: ^.*-docbuild-rst* 
files: 

- ^docs/.*$ 

- ^doc/.*$ 

=- .*N.rst 
Skip-if: 

- all-files-match-any: 

- ^docs/com/.*$ 


3. 在 Jenkins 中 添加 任务 
项 目 真 正 需要 执行 的 Job 定 义 在 Jenkins 中 ， 这 些 Job 的 定义 位 于 jenkins/jobs/ 目 录 中 ， 该 目录 包含 4 类 文件 : 

- defaults.yam]: Jenkins Jobs 默 认 参 数 定义 文件 。 

- macros.yaml: Jenkins Jobs 宏 定义 文件 。 

- «project, name».yaml: 特定 项 目的 Job 配 置 文件 。 

`- projects.yaml: 项 目 模板 的 实例 化 文件 。 
对 于 特定 项 目 ， 除 了 < project_name>.yaml 这 个 文件 外 ， 其 他 3 类 文件 可 以 根据 实际 需要 选择 配置 。 对 于 openzero 项 目 ， 需 要 增加 openzero.yam| 文 件 定义 。 

(1) Defaults 

该 配置 位 于 defaults.yaml 文 件 中 ， 以 -defaults: 行 开始 。 如 代码 清单 10-30 是 一 个 定义 示例 。 


代码 清单 10-30 Jenkins default 定 义 


- defaults: 
name: global 
project-type: freestyle 
concurrent: true 


wrappers: 

- timeout: 
timeout: 30 
fail: true 
- timestamps 


logrotate: 
daysToKeep: 1 
numToKeep: -1 
artifactDaysToKeep: -1 
artifactNumToKeep: -1 


示例 中 global 表 明 该 默认 配置 全 局 有 效 ， 项 目 类 型 是 freestyle， 人 允许 Jobs 并 行 执行 ，Job 执 行 的 超时 时 间 是 30 分 钟 ， 日 志 上 报时 需要 打 时 间 戳 ， 定 义 的 最 后 还 指定 了 日 志 的 默认 保存 策略 。 可 以 根据 需 
要 增加 其 他 参数 定义 。 


(2) Macros 


该 配置 位 于 macros.yaml 文 件 中 ， 宏 为 Job 定 义 的 复 用 提供 了 很 大 的 方便 ， 在 使 用 时 直接 使 用 宏 名 称 即 可 。 前 文 配 置 pipeline 时 为 openzero 项 目 定义 了 两 个 Job， 每 个 Job 都 会 复制 待 测 项 目 、 上 传 日 志 
等 ， 我 们 把 这 些 公共 的 部 分 定义 为 安 ， 如 代码 清单 10-31 所 示 的 是 为 openzero 项 目 增加 的 宏 定义 。 


代码 清单 10-31 openzero Jenkins Macros 定 义 


- builder: 
name: zuul-git-prep 
builders: 
- shell: | 
#!/bin/bash -xe 
CLONEMAP=`mktemp` 
function cleanup { 
mkdir -p $WORKSPACE 
rm -f $CLONEMAP 
} 
trap cleanup EXIT 
cat > SCLONEMAP << EOF 
clonemap: 
- name: $ZUUL PROJECT 
dest: . 
EOF 
/usr/zuul-env/bin/zuul-cloner -m SCLONEMAP --cache-dir /opt/git \ 
ssh://openzeroci@gerrit.oz:29418 $ZUUL PROJECT 
- publisher: 
name: console-log 
publishers: 
= Scp: 
site: 'LogServer' 
files: 


- target: 'logs/S$LOG PATH' 
copy-console: true 
copy-after-failure: true 


宏 zuul-git-prep 完 成 项 目 在 Slave 上 的 复制 操作 ， 宏 git-clone-opnfv-scripts 会 下 载 需要 的 运行 脚本 。 
(3) Job 


对 于 Job 定 义 ， 除 了 直接 定义 Job 外 ， 还 可 以 将 Job 定 义 为 模板 ， 以 便 多 个 Job 复 用 ; Job 模 板 的 定义 一 般 也 是 放 在 项 目 特 有 的 定义 文件 openzero.yaml 中 。 通 过 模板 ， 可 以 批量 定义 Job， 和 Zuul 中 的 项 
目 模板 一 样 ， 定 义 Job 模 板 一 般 也 会 携带 变量 ， 供 具体 实例 化 时 使 用 。 代 码 清单 10-32 是 Job 模 板 定义 示例 。 


代码 清单 10-32  openzero Jenkins Job 模 板 定 义 


- job-template: 
name: 'íname]-docbuild-rst' 
node: ubuntu-trusty 


doc dir: "docs" 
builders: 
- zuul-git-prep 
- shell: | 
$!/bin/bash -xe 
sudo apt-get update 
sudo apt-get install -y graphviz 
export DOCS DIR-'(doc dir]' 
/tmp/ releng/docs/scripts/docs-build.sh 
publishers: 
- console-log 


- job-template: 
name: 'íname)-docbuild-rst-release' 
node: ubuntu-trusty 
doc dir: "docs" 
builders: 
- zuul-git-prep 
- shell: | 
f!/bin/bash -xe 
export DOCS DIR-'í(doc dir]' 
/tmp/ releng/docs/scripts/docs-build.sh 


f remain issue: 
# java can not upload docs output to octopus.oz 
scp -r docs output/* deployGoctopus.oz:/home/deploy/docs/ {name} 
publishers: i 
- console-log 


openzero 定 义 了 两 个 项 目 模板 ， 即 '(namej-docbuild-rst' 和 '(namej-docbuild-rst-release, ' 模板 中 都 引用 两 个 宏 定义 zuul-git-prep 和 git-clone-opnfv-scripts， 并 增加 文档 发 布 和 日 志 上 报 两 
个 宏 。 

(4) project 

如 果 定义 了 Job 模 板 ， 要 将 这 些 模板 实例 化 为 具体 的 Job， 就 必须 定义 project，project 的 定义 位 于 文件 projects.yam| 中 。 代 码 清单 10-33 展 示 了 代码 清单 10-32 具 体 实例 化 的 过 程 。 


代码 清单 10-33 openzero Jenkins project 定 义 


- project: 
name: openzero 
project: 'íname]' 
reveal path: 'reveal' 


jobs: 
- '(name]-docbuild-rst' 
- '(name]-docbuild-rst-release' 
4. 修 改 Nodepool 配 置 


对 于 新 增 项 目 ， 一 般 不 涉及 Nodepool 的 配置 ， 但 是 为 项 目 定义 的 Job 如 果 需 要 运行 在 特殊 的 Slave 上 ,或 者 项 目 Job 运 行 需 要 特殊 的 镜像 支撑 ， 就 需要 重新 制作 镜像 、 从 云 中 创建 VM 并 打上 新 的 标签 
型 。 这 种 情况 下 ， I pus provider 和 diskimage 三 个 配置 项 的 变更 ， 该 配置 位 于 nodepool/nodepool.yaml 中 ， 在 前 文 10.2.2 节 中 已 经 有 相关 解释 ， 此 处 不 再 歼 述 ， Ne 
体 配 置 及 其 含义 请 参见 第 6 章 。 


[1] https://github.com/openstack-infra/project-conf ig/blob/before-jenkins-conf igremoved/zuul/layout.yaml o 


10.4.2 ”提交 变更 


对 于 普通 开发 人 员 来 说 ,一般 不 会 增加 项 目 ， 更 多 的 是 为 既 有 项 目 做 贡献 ， 为 了 能 提交 变更 到 项 目 中 ， 需 要 做 一 些 准 备 工 作 ， 包 括 创建 Gerrit 账 户 、 安 装配 置 git-review 工 具 等 ， 下 面 分 别 加 以 说 明 。 
1. 准 备 工 作 
(1) 创建 Gerrit 用 户 


要 向 系统 提交 变更 ， 需 要 创建 一 个 Gerrit 账 户 ， 为 简化 处 理 ，Gerrit 没 有 对 接 认证 系统 ， 所 以 普通 用 户 还 不 能 自己 创建 ， 只 能 由 具有 管理 权限 的 用 户 代为 创建 。 可 以 通过 Gerrit Web UI 创建 账户 ， 如 图 
10-21 所 示 。 


创建 时 需要 提供 用 户 名 、email 和 SSH 公 钥 等 。 
除了 Web Ul 外， 还 可 以 通过 CLI 的 方式 创建 账户 ， 如 代码 清单 10-34 所 示 。 


代码 清单 10-34 ”通过 CLI 创 建 Gerrit 用 户 


cat «your ssh pub key file» | ssh -p 29418 «admin name>@<gerrit-serer> gerrit \ 
create-account «acount name» --email «your email» --full-name «your name» \ 
--http-password «default password» --ssh-key - 


创建 完 账 号 后 ， 按 照 如 下 方式 配置 git: 


git config --global user.name «acount name» 
git config --global user.email «your email» 


All My Projects People Documentation 
Changes Drafts Draft Comments Edits Watched Changes Starred Changes — Groups 


Welcome to Gerrit Code Review 


Please review your contact information: 
The following contact information was automatically obtained when you signed-in to the site. This 


information is used to display who you are to others, and to send updates to code reviews you have 
either started or subscribed to. 


Full Name 
Preferred Email 


Save Changes 


Select a unique username: | 
Lisername Select Username 


Register an SSH public key: 
Gerrit Code Review uses public-key cryptography and SSH to authenticate you during git's push and 
pull commands to hosted projects. Registering your public key allows Gerrit to identify you whenever 
you connect through SSH. 
This step can also be completed at a later time. 


Add SSH Public Key 
= How to Generate an SSH Key 


Clear | Add | 


Server Host Key 


Fingerprint: 
47:e66:65:06:£9:0a:6a:B6:47:15:9b:£fa:0£:93:687:a4 


Entry for -/.ssh/known hosts: 


[172.80.0.17]:29418 ssh-rsa AAAAB3NZAaClyc2EAAAADAQABAAAAqQCrbA3qvKHxeV...nnykRySwsm | 


图 10-21 通过 Web 创 建 Gettit 用 户 
(2) 安装 git-review 


开发 环境 使 用 git-review 作 为 代码 评审 提交 工具 ， 通 过 下 面 方式 安装 : 


apt-get install git-review 


2. 为 新 项 目 做 贡献 


为 新 项 目 做 贡献 ， 首 先 需 要 复制 代码 ， 如 下 所 示 : 


git clone ssh://shangxqyQdgerrit.cibook.oz:29418/openzero/openzero 


接着 需要 为 项 目 配置 Gerrit (此 时 也 可 以 不 配置 ， 在 第 一 次 提交 变更 时 Gerrit 会 提示 增加 配置 ) : 


cd openzero 

git config --global gitreview.username «acount name» 

git remote add gerrit https://«acount name»8«project repository url» 
git review -s E E 


最 后 一 行 命令 会 检查 用 户 是 否 可 以 通过 SSH 公 钥 登 录 Gerrit， 如 果 成 功 没 有 任何 返回 ， 否 则 会 返回 错误 信息 。 


项 目 配置 完毕 之 后 ， 在 本 地 创建 并 检 出 分 支 ， 然 后 可 以 修改 代码 了 : 


git checkout -b «topic-branch» 


修改 完毕 并 经 过 本 地 测试 后 ， 提 交代 码 : 


git commit -am "< 注释 >" 


最 后 提交 到 Gerrit 系 统 进行 评审 : 


git review 


提交 到 Gerrit 后 其 他 人 员 会 进行 评审 ， 如 图 10-22 所 示 。 


co 
从 Slave 和 Jenkins 交互 的 角度 ，Slave 分 为 动态 Slave 和 静态 Slave, 8975 Slave 需要 手动 添加 到 
rt ee Jenkins 中 ， 并 一 直 存在 于 Jenkins 中 ， 直 到 再 次 手动 从 Jenkins 中 删除 ， 静 态 Slave 可 以 是 物理 
机 、 虚 机 或 容器 ; 动态 Slave 都 是 是 通过 工具 自动 管理 其 生命 期 的 ， 即 先 通过 工具 创建 Slave， 然 
$ 后 注册 到 Jenkins 中 ， 使 用 完毕 后 自动 从 Jenkins 中 删除 ， 动 态 Slave 目前 只 能 以 虚 机 的 形式 存在 。 
由 于 是 人 为 控制 ， 所 以 静态 Slave 可 以 在 同一 个 生命 期 多 次 运行 测试 任务 ， 这 些 测试 可 能 相关 ， 也 
可 能 不 相关 ， 而 动态 Slave 是 按 自动 化 流程 控制 各 生命 节点 的 ， 一 次 生命 期 只 运行 一 个 测试 任务 ， 
任务 运行 完 Slave 生命 期 就 结束 了 ; NodePool 系统 就 是 这 样 的 Slave 生命 期 自动 化 管理 工具 。 
NodePool、jenkins 及 Slave 关系 如 下 图 所 示 : 


Publisher evnets 


*— — —-Assigne nodes 


1. DevOps 
2. CI/CD 


3. 版 本 控制 (Git) 5S C ESTER (Gerrit) 


6. 持续 集成 系统 (Jenkins) 
87. 资源 管理 系统 (NodePool) 
3 7.1. NodePool 简 介 
3 7.2. 安装 NodePool 
$ 7.3. NodePool 原 理 
3 7.4. 配 置 NodePool 


需要 说 明 的 是 ，NodePool 管理 的 Slave， 不 仅 可 以 提供 独立 的 VM， 还 可 以 是 一 组 VM， 组 内 VM 
| 彼此 互通 ， 但 是 在 Jenkins 看 来 就 像 只 有 一 个 VM， 这 种 情况 是 为 满足 一 次 测试 需要 多 个 VM 协同 
275. 镜像 管理 系统 工作 的 复杂 场景 而 设计 的 ， 例 如 测试 kubernetes， 一 个 VM 用 做 kubernetes master， 其 余 做 

3 7.6. 高 级 话题 kubernetes node, 


7.7. 本 章 小 结 
7.8. 参考 文献 如 前 所 述 ， 当 前 NodePool 仅 管 理 VM， 所 以 NodePool 功能 上 都 是 围绕 VM 而 来 的 ， 主 要 分 两 大 
8. Jenkins H EDITAR 部 分 : 
9. OpenStack 社 区 Cl/CD 最 住 实践 。 VM 管理 相关 功能 
10. OpenStack 社 区 CIMCD 演 进 和 发 展 1. 云 配 置 管理 : 对 接 一 个 或 多 个 云 环境 ; 
2. VM 生命 期 管理 : 按照 配置 和 当前 Slave 使 用 情况 在 云 环境 中 创建 VYM， 使 用 完毕 后 删除 
VM; 


图 10-22 ”提交 变更 


openzero 项 目 每 次 变更 提交 后 ， 都 会 发 布 临 时 htm| 文 档 ， 通 过 Job 运 行 结 果 中 的 链接 可 以 看 到 html 编 译 结果 ， 如 图 10-23 所 示 。 


eX 23 D gerrit.cibook. SEE E -docbuild-rst/92fc910/docs output/book/nodepool.html 
| Gerit ft 
f$ openzero-docbuild-rst | | testresults 
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job configifration 


, wm 

test results SS 

job triggers orce node ^ "Ez 
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Gearman 人 Job template 
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plugin y 


Log storage server 


* 


publish 


HTTPd I d job output : Me t 
Logs | : ” DO NodePool 
| i Master |~ 


ZMQ publisher : 
plugin b 


CI log server 
(optional) 


] [ ] f W commands CI SI 
Elastic | : a ave 
Kibana 一 *——1Logstash f| : 


search | ; : | trigger with 
— | | ed Jenkins i 


Search docs Agent 


views CI logs ( OpenStack CI : 
| 和 system : triggérs & reads output 
1. DevOps \ ) administrator : 


2. CI/CD 


service logs 


delivery | Release Job 
3. 版 本 控制 (Git) 与 代码 评审 Artifacts P Under Test 
(Gerrit) : 


4. 持续 集成 系统 (Jenkins) 


5 门 控 系统 (Zuul Æ 6.1 NodePool 在 Open5Stack CI/CD 中 的 位 置 

日 4 PRERE (NodePool) 图 中 黑色 框 里 面 即 是 NodePool 包含 的 范畴 ， 灰 色 部 分 为 其 他 组 件 。 从 Slave 和 Jenkins 交互 的 角 
3 6.1. NodePool 简 介 度 ，Slave 分 为 动态 Slave 和 静态 Slave, 8$; Slave 需要 手动 添加 到 Jenkins 中 ， 并 一 直 存 在 于 
3 6.2. 安装 NodePool Jenkins 中 ， 除 非 手 动 从 Jenkins 中 删除 ， 静 态 Slave 可 以 是 物理 机 、 虚 机 或 容器 ; 动态 Slave 一 般 
5.6.3. NodePoollUR 是 通过 自动 化 工具 管理 其 生命 期 的 ， 即 先 通过 工具 创建 Slave， 然 后 注册 到 Jenkins 中 ， 使 用 完毕 


后 自动 从 Jenkins 中 删除 ， 动 态 Slave 目前 多 以 虚 机 的 形式 存在 。 由 于 是 人 为 控制 ， 所 以 静态 Slave 


3 6.4. 配 置 NodePool 可 以 在 同一 个 生命 期 多 次 运行 测试 任务 ， 这 些 测试 可 能 相关 ， 也 可 能 不 相关 ， 而 动态 Slave 是 按 自 


3 6.5. 镜像 管理 系统 动 化 流程 控制 各 生命 节点 的 ， 一 次 生命 期 只 运行 一 个 测试 任务 (Slave executors 默认 为 1) ， 任 务 
6.6. 本 章 小 结 运行 完 Slave 生命 期 就 结束 了 ，NodePool 系统 就 是 这 样 的 Slave 生命 期 自动 化 管理 工具 ， 其 和 


7. 日 志 服 务 器 Jenkins 及 Slave 关系 如 图 6.2 所 示 。 


8. 日 志 分 析 系 统 


9. 公共 组 件 介绍 
10. 社区 CI/CD SÈ 
11. 演进 


Nodepool 


E 6.2 NodePool 5 Jenkins A] Slave 的 关系 


图 10-23  openzero html X Bi A 7p 25 


根据 评审 意见 和 CI/CD 运 行 结果 ， 可 能 会 经 过 多 次 修改 和 提交 ， 在 此 过 程 中 可 以 充分 利用 Gerrit 系 统 和 评审 者 进行 沟通 交流 ， 直 到 代码 合 入 到 目标 分 支 中 。 代 码 合 入 目标 分 支 后 ， 会 生成 并 发 布 pdf 文 
档 ， 如 图 10-24 所 示 是 发 布 结果 


10.4.3 ”定制 优化 


1.Puppet 模 块 定制 


部 署 Cl master 时 ， 需 要 从 Internet 上 下 载 安装 很 多 Puppet 模 块 ， 导 致 安装 时 间 非 常 长， 而 这 些 模块 大 部 分 是 用 来 部 署 OpenStack 基 础 设施 或 者 Openstack 组 件 服务 的 ， 对 于 企业 内 部 CI| 应 用 来 说 大 部 
分 不 需要 ， 因 此 可 以 裁减 掉 这 些 元 余 的 Puppet 模 块 。 


€ a Q artifacts.cibook.oz/docs/openzero/OpenstackCICD.pdf 


Slave 分 为 动态 Slave 和 静态 Slave ; 静态 Slave 需要 人 为 添加 到 Jenkins 中 ， 并 一 直 存 在 于 Jenkins 
中 ,直到 再 次 人 为 从 Jenkins 中 删除 ,静态 Slave 可 以 是 物理 机 、 虚 机 也 可 以 是 容器 ; 动态 Slave 都 是 通 
过 工具 管理 其 生命 期 的 ， 一 般 通 过 工具 先 自动 创建 Slave ， 然 后 加 入 Jenkins 中 ,使 用 完毕 后 自动 从 
Jenkins 中 删除 , 动态 Slave 目前 只 能 以 虚 机 的 形式 存在 ; 由 于 是 人 为 控制 ,所 以 静态 Slave 可 以 在 同一 
个 生命 期 多 次 运行 Job , 3x!* Job 可 能 相关 , 也 可 能 不 相关 ， 而 动态 Slave 是 严格 按 自动 化 流程 控制 各 生 
命 节点 的 ， 一 次 只 运行 一 个 Job , Job 运行 完 Slave 生命 期 就 结束 了 (严格 的 说 , 同一 Slave 可 以 有 多 个 
Executor , 一 个 Executor 承载 一 个 Job ,一 个 Job 消费 一 个 Executor , 要 所 有 Executor 都 消耗 完 
Slave 的 使 命 才 算 结束 ; 不 过 为 了 方便 描述 ,我 们 都 假设 一 个 Slave 只 有 一 个 Executor ) ; NodePool 
系统 就 是 这 样 的 Slave 生命 期 自动 化 管理 工具 。NodePool、Jenkins 及 Slave 关系 如 下 图 所 示 : 


需要 说 明 的 是 ，NodePool 不 仅 可 以 提供 独立 的 VM 作为 Slave ,还 可 以 为 Slave 准备 一 组 VM , ji 
足 复杂 测试 场景 的 需要 ， 


如 前 所 述 , 当前 NodePool 仅 管理 VM , 所 以 NodePool 功能 上 都 是 围绕 VM 而 来 的 ， 主 要 分 两 大 


第 6 章 ”资源 管理 系统 (NodePool) 


图 10-24  openzero bdf 文 档 发 布 结果 
安装 Puppet 模 块 的 配置 文件 位 于 system-config/modules.env。 裁 剪 之 前 的 定制 模块 大 致 分 为 如 下 几 部 分 : 


: OpenStack 组 件 部 署 模块 : 包括 puppet-keystone、puppet-cindetr、puppet-glance、puppet-ironic、puppet-neutron、puppet-nova、puppet-openstack_extras 和 puppet-openstacklib， 如 果 企 业内 部 不 做 OpenStack 部 
署 测试 ， 这 一 部 分 都 可 删除 。 


OpenStack-infra 组 件 部 署 模块 : 按照 部 署 CI 系 统 需 要 用 到 的 组 件 服 务 裁剪 ， 比 如 多 节点 系统 部 署 需求 ， 保 留 Puppet-gettit、puppet-zuul、puppetrnodepool、puppet-jenkins 和 puppetropenstackci 等 模块 ， 其 他 
可 以 删除 。 


. GitHub 上 一 些 公共 组 件 部 署 模块 : 一 些 公共 组 件 部 署 模块 ， 比 如 Zookeeper、mysql、ntp 等 ， 这 些 模块 不 在 OpenStack 的 git 库 下 。 保 留 部 署 CT 系统 用 到 的 公共 组 件 模块 即 可 ， 其 他 可 以 删除 。 
最 终 裁剪 后 的 Puppet 模 块 配置 如 代码 清单 10-35 所 示 。 


代码 清单 10-35 ”裁剪 后 的 Puppet 模 块 配置 


OPENSTACK GIT ROOT=https://git.openstack.org 


# InfraCloud modules 
SOURCE MODULES ["https://git.openstack.org/openstack-infra/puppet-vcsrepo"]- 


RCE MODULES ["https: //github.com/deric/puppet-zookeeper"]-"v0.5.5" 
ODULES ["https: //github.com/duritong/puppet-sysctl"]-2"v0.0.11" 

LES ["https://github.com/jethrocarr/puppet-initfact"]-2"1.0.1" 
["https://github.com/jfryman/puppet-selinux"]-"v0.2.5" 
["https://github.com/maestrodev/puppet-wget"]-"v1.6.0" 
["https://github.com/nltr0g/golja-gnupg"]-"1.2.2" 
["https://github.com/nanliu/puppet-staging"]-2"1.0.0" 
["https://github.com/puppetlabs/puppetlabs-apache"]2"1.8.1" 
ES ["https://github.com/puppetlabs/puppetlabs-apt"]-"2.1.0" 
["https://github.com/puppetlabs/puppetlabs-concat"]2"1.2.5" 
["https://github.com/puppetlabs/puppetlabs-firewall"]2"1.1.3" 
["https://github.com/puppetlabs/puppetlabs-haproxy"]-2"1.5.0" 
["https://github.com/puppetlabs/puppetlabs-inifile"]-"1.1.3" 
["https://github.com/puppetlabs/puppetlabs-java ks"]-"1.3.1" 
["https://github.com/puppetlabs/puppetlabs-mysqi"]2"3.6.2" 
["https://github.com/puppetlabs/puppetlabs-ntp"]-"3.2.1" 
["https://github.com/puppetlabs/puppetlabs-postgresql"]2"3.4.2" 
iS ["https://github.com/puppetlabs/puppetlabs-puppetdb"]2"3.0.1" 
["https://github.com/puppetlabs/puppetlabs-rabbitmq"]-"5.2.3" 
["https://github.com/puppetlabs/puppetlabs-stdlib"]2"4.10.0" 
["https://github.com/rafaelfelix/puppet-pear"]-"1.0.3" 
["https://github.com/saz/puppet-memcached"]-"v2.6.0" 
["https://github.com/saz/puppet-timezone"]-"v3.3.0" 
["https://github.com/stankevich/puppet-python"]-"1.9.4" 

ES ["https://github.com/voxpupuli/puppet-alternatives"]-"0.3.0" 
["https://github.com/voxpupuli/puppet-archive"]-2"v0.5.1" 
["https://github.com/voxpupuli/puppet-git resource"]-"0.3.0" 
["https://github.com/voxpupuli/puppet-nodejs"]-2"1.2.0" 
["https://github.com/voxpupuli/puppet-puppetboard"]-"2.4.0" 
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4 Add modules that should be part of the openstack-infra integration test here 

# Please keep sorted 

NTEGRATION MODULES["SOPENSTACK GIT ROOT/openstack-infra/puppet-ansible"]-"origin/ 
master" 

NTEGRATION MODULES["SOPENSTACK GIT ROOT/openstack-infra/puppet-cgit"]-"origin/ 
master" 

NTEGRATION MODULES["SOPENSTACK GIT ROOT/openstack-infra/puppet-diskimage builder"]- 
"origin/master" 

NTEGRATION MODULES["SOPENSTACK GIT ROOT/openstack-infra/puppet-elastic recheck"]- 
"origin/master" 

NTEGRATION MODULES["SOPENSTACK GIT ROOT/openstack-infra/puppet-elasticsearch"]- 
"origin/master" 

NTEGRATION MODULES["SOPENSTACK GIT ROOT/openstack-infra/puppet-ethercalc"]- 
"origin/!master" 

NTEGRATION MODULES["SOPENSTACK GIT ROOT/openstack-infra/puppet-etherpad lite"]- 
"origin/master" 

NTEGRATION MODULES["SOPENSTACK GIT ROOT/openstack-infra/puppet-gerrit"]-"origin/ 
master" 

NTEGRATION MODULES["SOPENSTACK GIT ROOT/openstack-infra/puppet-gerritbot"]- 
"origin/master" 

NTEGRATION MODULES["SOPENSTACK GIT ROOT/openstack-infra/puppet-github"]-"origin/ 
master" 

NTEGRATION MODULES["SOPENSTACK GIT ROOT/openstack-infra/puppet-httpd"]-"origin/ 
master" 

NTEGRATION MODULES["SOPENSTACK GIT ROOT/openstack-infra/puppet-infracloud"]-"origin/ 
master" 

NTEGRATION MODULES["SOPENSTACK GIT ROOT/openstack-infra/puppet-iptables"]-"origin/ 
master" 

NTEGRATION MODULES["SOPENSTACK GIT ROOT/openstack-infra/puppet-jeepyb"]-"origin/ 
master" 

NTEGRATION MODULES["SOPENSTACK GIT ROOT/openstack-infra/puppet-jenkins"]-"origin/ 
master" 

NTEGRATION MODULES["SOPENSTACK GIT ROOT/openstack-infra/puppet-kerberos"]-"origin/ 
master" 

NTEGRATION MODULES["SOPENSTACK GIT ROOT/openstack-infra/puppet-kibana"]-"origin/ 
master" 

NTEGRATION MODULES["SOPENSTACK GIT ROOT/openstack-infra/puppet-log processor"]- 
"origin/master" 

NTEGRATION MODULES["SOPENSTACK GIT ROOT/openstack-infra/puppet-logrotate"]-"origin/ 
master" 

NTEGRATION MODULES["SOPENSTACK GIT ROOT/openstack-infra/puppet-logstash"]-"origin/ 
master" 

NTEGRATION MODULES["SOPENSTACK GIT ROOT/openstack-infra/puppet-mysql backup"]- 
"origin/master" 

NTEGRATION MODULES["SOPENSTACK GIT ROOT/openstack-infra/puppet-nodepool"]-"origin/ 
master" 

NTEGRATION MODULES["SOPENSTACK GIT ROOT/openstack-infra/puppet-openstackci"]- 
"origin/master" 

NTEGRATION MODULES["SOPENSTACK GIT ROOT/openstack-infra/puppet-pip"]-"origin/master" 
NTEGRATION MODULES["SOPENSTACK GIT ROOT/openstack-infra/puppet-project config"]- 
"origin/master" 

NTEGRATION MODULES["SOPENSTACK GIT ROOT/openstack-infra/puppet-simpleproxy"]-"origin/ 
master" 

NTEGRATION MODULES["SOPENSTACK GIT ROOT/openstack-infra/puppet-snmpd"]-"origin/ 
master" 

NTEGRATION MODULES["SOPENSTACK GIT ROOT/openstack-infra/puppet-ssh"]-"origin/master" 
NTEGRATION MODULES["SOPENSTACK GIT ROOT/openstack-infra/puppet-ssl cert check"]- 
"origin/master" 

NTEGRATION MODULES["SOPENSTACK GIT ROOT/openstack-infra/puppet-sudoers"]-"origin/ 
master" 

NTEGRATION MODULES["SOPENSTACK GIT ROOT/openstack-infra/puppet-user"]-"origin/ 
master" 

NTEGRATION MODULES["SOPENSTACK GIT ROOT/openstack-infra/puppet-zuul"]-"origin/ 
master" 

pm 

r9. 

uis 


代码 清单 10-35 所 示 的 只 是 当前 作者 环境 定制 的 情况 ， 读 者 可 以 结合 实际 需要 在 社区 默认 配置 的 基础 上 增加 或 删除 相应 模块 ; 此 外 ， 由 于 社区 使 用 OpenStack 主 分 支 的 模块 配置 ， 因 此 随 着 版 本 的 不 同 ， 
社区 默认 模块 列表 也 可 能 会 有 变化 。 


2. 镜 像 裁 荔 和 定制 
Nodepool 编 译 的 镜像 是 为 Dpenstack 社 区 定制 的 ， 编 译 过 程 中 在 线 下 载 安 装 了 很 多 Openstack 项 目的 软件 包 以 及 相关 的 测试 项 目 ， 存 在 以 下 问题 : 
` 镜像 非常 大 ， 原 始 镜像 2G 左 右 ; 
` 编译 时 间 非 常 长 ， 差 不 多 需要 4 小 时 ， 而 且 如 果 网 络 带 宽 不 好 的 话 ， 编 译 过 程 中 任意 一 步 失 败 ， 编 译 过程 又 需要 重新 开始 ; 
- 在 云 环 境 上 launch 节 点 的 时 候 ， 要 执行 定制 化 的 操作 ， 导 致 从 节点 launch 到 注册 到 Jenkins 服 务 器 的 时 间 最 长 可 超过 10 分 钟 ; 
. 镜像 不 满足 测试 场 最 的 需求 ， 缺 少 所 需 的 软件 包 ， 比 如 docket; 当然 可 以 在 任务 中 按 需 安装 ， 但 不 推荐 使 用 这 种 做 法 。 
针对 以 上 问题 ， 在 企业 内 部 应 用 中 需要 对 镜像 做 裁剪 和 定制 ， 下 面 分 别 对 裁剪 和 定制 做 说 明 。 
(1) R 
原 有 Nodepool 配 置 的 所 有 镜像 elements 如 代码 清单 10-36 所 示 。 


代码 清单 10-36 ”elements 列 表 


diskimages: 
- name: ubuntu-trusty 
elements: 

- ubuntu-minimal 
= um 
- infra-package-needs 
- jenkins-slave 
- simple-init 
- cache-devstack 
- openstack-repos 
- nodepool-base 
- prepare-node 
- zuul-worker 
- growroot 
- stackviz 


其 中 : 

ubuntu-minimal: 基础 操作 系统 。 
vm: 设置 分 区 磁盘 。 

simple-init: 设置 基础 网 络 和 系统 配置 。 


growroot: 扩展 根 分 区 。 


以 上 几 个 是 基础 镜像 elements， 不 做 裁剪 。 
- infra-package-needs: 安装 基础 包 ， 比 如 git、cron、cutl、git-teview、tox、 设 置 系 统 日 志 配 置 文件 等 ， 可 以 不 修改 。 
: jenkins-slave: 设置 Jenkins 用 户 下 git 的 配置 及 用 户 登 录 的 认证 公 钥 等。 


 openstack-repos: 下 载 所 有 需要 的 OpenStack 包 ， 从 project-conf ig/getrit/projects.yaml 文 件 中 读 取 所 有 的 项 目 列 表 然 后 下 载 安 装 。 社 区 默认 配置 有 2000 多 个 项 目 ， 大 部 分 在 企业 CI 中 都 用 不 到 ， 删 除 所 有 
不 使 用 的 项 目 ， 注 册 所 需 的 项 目 即 可 。 这 一 步 可 以 大 大 减少 镜像 大 小 ， 缩 短 镜像 编译 时 间 。 


- cache-devstack: 缓存 所 有 devstack 可 能 需要 用 到 的 包 和 库 ， 如 果 不 做 OpenStack 部 署 ， 可 以 删除 该 element。 
- nodepool-base: 处 理 镜像 元 数据 以 及 一 些 和 云 相关 的 调整 。 

` prepare-node: 准备 节点 ， 主 要 在 Jenkins 用 户 下 创建 了 一 些 缓存 文件 夹 ， 可 以 删除 。 

: zuul-wotker: 在 Zuul 用 户 下 设置 相关 配置 使 zuul-wotket 处 理 程序 可 以 远程 登录 ， 可 以 删除 。 

* stackviz: 安装 stackviz 并 构建 npm 依 赖 。 


nodepool.yam| 的 配置 label 下 有 一 个 ready-script 参 数 ， 该 参数 配置 为 一 个 脚本 名 称 ， 在 节点 孵化 完成 后 注册 到 Jenkins 之 前 调用 该 脚本 执行 ， 社 区 默认 配置 为 conf igure_mirror.sh。 该 脚本 用 来 设置 
DNS、 检 查 git.openstack.org 域 名 地 址 是 否 能 正常 访问 、 设 置 pip 配 置 文件 以 及 在 系统 的 包 管 理工 具 中 增加 额外 的 包 地 址 等 。 裁 剪 时 删除 大 部 分 配置 ， 修 改 DNS 为 企业 内 部 域名 服务 器 地 址 ， 如 代码 清单 10- 
37 所 示 。 


代码 清单 10-37 configure_mirror.sh 


# set DNS address for openstack env 
echo "nameserver 172.10.0.1" |sudo tee /etc/resolv.conf 


echo "127.0.0.1 localhost"|sudo tee /etc/hosts 
echo "127.0.1.1 ubuntu"|sudo tee -a /etc/hosts 


cat << EOF > -«/.ssh/config 
Host * 
StrictHostKeyChecking no 


EOF 


裁剪 前 后 性 能 对 比如 表 10-2 所 示 ， 可 以 看 出 指标 得 到 明显 提升 。 


表 10-2 镜像 裁剪 前 后 性 能 对 比 


指标 裁剪 前 zd. BU o 
镜像 大 小 (M) 1400 400 
编 详 时 间 (min) 240 40 
注册 时 间 (min) 10 3 


(2) 定制 
以 安装 docker 为 例 ， 说 明 如 何 定 制 elements。 
因为 已 有 名 字 为 docker 的 element， 但 是 完成 的 不 是 安装 docker 的 功能 ， 所 以 这 里 不 使 用 docker 作 为 名 字 。 新 增 名 为 openzero 的 element， 目 录 结 构 如 代码 清单 10-38 所 示 。 


代码 清单 10-38 openzero element 


element-deps 
install.d 
35-docker 
README.rst 


L— daemon.json 


因为 是 安装 qocker 软 件 ， 所 以 对 应 DIB 镜 像 制 作 8 个 阶段 中 的 软件 安装 阶段 ， 即 需要 增加 install.d 目 录 ， 该 目录 下 存放 执行 的 脚本 代码 ， 如 代码 清单 10-39 所 示 。 
代码 清单 10-39 ”安装 docker 


#!/bin/bash 


if [ S(DIB DEBUG TRACE:-0} -gt 0 ]; then 


set -x 
fi 

set -eu 

set -o pipefail 


export SUDO-'true' 

export THIN-'true' 

sudo apt-get install -y apt-transport-https ca-certificates 

sudo apt-key adv --keyserver hkp://ha.pool.sks-keyservers.net:80 \ 
--recv-keys 58118E89F3A912897C070ADBF76221572C52609D 

echo "deb [arch-amd64] http://mirrors.oz/docker-ce xenial stable" | \ 
sudo tee /etc/apt/sources.list.d/docker.list 


sudo apt-get update 

sudo apt-cache policy docker-engine 

sudo apt-get update 

sudo apt-get install -y linux-image-extra-$ (uname -r) linux-image-extra-virtual 
sudo apt-get install -y docker-engine 

# Add jenkins user to docker group 

sudo usermod -aG docker jenkins 


接 下 来 需要 设置 docker 的 配置 文件 ， 准 备 好 配置 文件 daemon.json， 如 代码 清单 10-40 所 示 。 其 中 registry-mirrors 可 设置 为 docker 的 官方 镜像 源 ， 也 可 使 用 内 部 源 。 


代码 清单 10-40 ”docker 配 置 文件 


"max-size": "50m" 


"registry-mirrors": [ 
"https: //dockerhub.oz" 


] 


, 
"log-driver": "json-file" 


使 用 已 有 的 element install-static， 该 element 的 功能 是 复制 所 有 element 下 /static 目 录 的 内 容 到 镜像 中 。 因 此 把 准备 好 的 配置 文件 daemon.json 放 在 openzero/static/etc/docker/ 目 录 下 ， 镜 像 编译 
过 程 中 会 把 /etc/dockevdaemon.json 原 样 复制 到 镜像 中 。 因 为 openzero 的 element 依 赖 于 install-static， 还 需要 把 install-static 写 入 文件 element-deps， 指 明 依 赖 关 系 。 


针对 以 上 镜像 裁剪 和 定制 的 优化 ， 最 终 在 nodepool.yam 刁 置 中 指定 的 element， 如 代码 清单 10-41 所 示 ， 可 以 看 到 删除 了 cache-devstack 和 prepare-node 两 个 elements， 新 增 了 openzero。 


代码 清单 10-41 定制 后 的 element 配 置 


diskimages: 
- name: ubuntu-trusty 
elements: 
- ubuntu-minimal 
vm 
infra-package-needs 
jenkins-slave 
simple-init 
openstack-repos 
nodepool-base 
zuul-worker 
growroot 
stackviz 
openzero 


3. 使 用 内 部 repo 

要 成 功 使 用 OpenStack CIMCD， 对 网 络 有 严格 的 要 求 ， 主 要 来 自 以 下 几 个 方面 : 

: Nodepool 在 制作 镜像 过 程 中 ， 需 要 从 官网 下 载 初始 镜像 和 大 量 的 安装 包 。 

: Job 执 行 过 程 中 由 于 任务 的 不 同 需要 下 载 各 种 各 样 的 安装 包 。 

. 有 些 Job 需 要 运行 docker， 需 要 下 载 容器 镜像 。 

从 官网 上 下 载 大 量 的 包 ， 由 于 网 络 带 宽 限 制 会 消耗 一 定 的 时 间 ， 而 且 如 果 网 络 不 稳定 会 导致 镜像 制作 或 Job 执 行 失败 。 解 决 这 些 问题 的 方式 就 是 使 用 企业 内 部 源 ， 包 括 : 
` apt/yum 源 : 软件 包 本 地 镜像 ， 并 保持 和 官网 源 同步 。 

- pip 源 : python 软 件 包 。 

` docker 镜 像 源 : 容器 镜像 。 

另外 ， 对 于 常用 的 尤其 是 较 大 的 文件 ， 如 果 不 属 于 以 上 类 别 ， 可 以 自己 构建 独立 的 http server， 作 为 文件 服务 器 ， 以 加 速 CMCD 运 行 过 程 中 的 访问 。 
如 何 搭建 各 repo 源 不 在 本 文 的 介绍 范围 内 ， 这 里 只 介绍 如 何 配置 这 些 本 地 源 。 首 先 介绍 下 如 何 修改 镜像 制作 的 源 。 

(1) 镜像 制作 源 

在 Nodepool 的 配置 文件 nodepool.yaml 中 ， 配 置 diskimages 环 境 变量 参数 DIB_DIST-RIBUTION_MIRROR 为 内 部 源 地 址 ， 如 代码 清单 10-42 所 示 。 


代码 清单 10-42 ”镜像 源 定制 


diskimages: 
- name: ubuntu-trusty 

rebuild-age: 864000 

elements: 
http: //www.hzcourse.com/resource/readBook?path-/openresources/teach ebook/uncompressed/17933/OEBPS/Text/... 
release: trusty 
env-vars: 
http: //www.hzcourse.com/resource/readBook?path-/openresources/teach ebook/uncompressed/17933/OEBPS/Text/... 
DIB DISTRIBUTION MIRROR: 'http://mirrors.cibook.oz/ubuntu' 
http: //www.hzcourse.com/resource/readBook?path-/openresources/teach ebook/uncompressed/17933/OEBPS/Text/.. 


示例 中 指定 镜像 编译 使 用 的 内 部 源 为 http://mirrors.cibook.oz/ubuntu。 

(2) 虚 机 内 部 源 

接 下 来 介绍 如 何 修改 虚 机 内 部 使 用 的 源 ， 通 常 有 两 种 方式 : 一 种 是 修改 elements; 另 一 种 是 在 虚 机 启动 之 后 注册 到 Jenkins 之 前 调用 脚本 配置 。 
1) 定制 element 

element jenkins-slave 用 来 设置 Jenkins 用 户 下 git 的 配置 及 用 户 登 录 的 认证 公 钥 等 ， 可 以 在 这 里 添加 /修改 各 源 的 配置 。 

element jenkins-slave 的 目录 结构 如 代码 清单 10-43 所 示 。 

代码 清单 10-43 jenkins-slave element 

[ puncture 


install.d 
20-jenkins-slave 


以 修改 pip 源 为 例 ， 在 20-jenkins-slave 文 件 中 添加 如 代码 清单 10-44 所 示 的 代码 段 。 
代码 清单 10-44 定制 pip 源 


mkdir /home/jenkins/.pip 
chmod 700 /home/jenkins/.pip 


cat «« EOF » /home/jenkins/.pip/pip.conf 
[global] 

index = http://nexus.oz/repository/pypi/ 

index-url = http://nexus.oz/repository/pypi/simple 


[install] 
trusted-host = nexus.oz 
EOF 


应 用 该 element 编 译 镜像 时 会 在 Jenkins 用 户 下 生成 pip 的 配置 文件 ， 即 修改 了 pip 的 源 地 址 。 其 他 修改 如 apt/yum 源 和 docker 源 修改 与 此 相同 ， 不 再 袭 述 。 
2) 脚本 配置 


社区 提供 的 conf igure_mirror.sh 脚 本 支持 通过 注入 环境 变量 的 方式 修改 虚 机 的 配置 。 即 在 Nodepool 服 务 的 节点 上 配置 以 NODEPOOL 开始 命名 的 环境 变量 ， 启 动 虚 机 后 ，Node-pool 会 将 这 些 环境 变 
量 注入 虚 机 中 ， 然 后 再 执行 conf igure_mirror.sh， 这 样 就 可 以 定制 虚 机 在 运行 过 程 中 使 用 的 apt 源 、pip 源 和 docker 镜 像 源 。 其 主要 参数 设置 如 代码 清单 10-45 所 示 。 


代码 清单 10-45 ”脚本 定制 内 部 源 


PIP CONF="\ 

[global] 

timeout - 60 

index-url = $NODEPOOL PYPI MIRROR 
trusted-host - SNODEPOOL MIRROR HOST 
extra-index-url = $NODEPOOL WHEEL MIRROR" 


PYDISTUTILS CFG="\ 

[easy install] 

index url = $NODEPOOL PYPI MIRROR 
allow hosts = *.openstack.org" 


UBUNTU SOURCES LIST="\ 

deb $NODEPOOL UBUNTU MIRROR $LSBDISTCODENAME main universe 

deb SNODEPOOL UBUNTU MIRROR S$LSBDISTCODENAME-updates main universe 
deb $NODEPOOL UBUNTU MIRROR SLSBDISTCODENAME-backports main universe 
deb $NODEPOOL UBUNTU MIRROR S$LSBDISTCODENAME-security main universe" 


http: //www.hzcourse.com/resource/readBook?path-/openresources/teach ebook/uncompressed/17933/OEBPS/Text/... 


export NODEPOOL DOCKER REGISTRY PROXY=$ {NODEPOOL DOCKER REGISTRY PROXY: \ 
-http://S$NODEPOOL MIRROR HOST:8081/registry-l.docker] 


如 示例 所 示 ， 只 要 在 Nodepool 节 点 上 配置 NODEPOOL PYPI MIRROR, NODEPOOL MIRROR HOST, NODEPOOL WHEEL MIRROR 和 NODE-POOL UBUNTU _MIRRO 等 环境 变量 即 可 。 
4. 多 云 接 入 


单机 部 署 实践 时 Nodepool 接 入 的 是 单个 云 环境 ， 当 单 云 故障 或 者 云 环境 维护 升级 ， 当 前 的 CI 系统 就 没有 可 用 的 slave 节 点 ， 所 以 支持 多 云 环境 接 入 变 得 很 有 必要 ， 其 系统 拓扑 结构 如 图 10-25 所 示 。 
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图 10-25 ”多 云 接 入 


在 图 10-25 中 ，Nodepool 连 接 了 两 个 云 环境 ， 当 一 个 云 环境 出 现 异 常 时 ，Nodepool 可 以 使 用 另 一 个 云 环境 为 Jenkins 服 务 。 其 配置 如 代码 清单 10-46 所 示 ， 两 个 云 环境 分 别 为 zte-pod11-RegionOne 
和 zte-pod13-RegionOne， 总 共 提 供 10 个 带 ubuntu-trusty 标 签 的 虚 机 和 6 个 带 upuntu-trusty-large 标 签 的 虚 机 ， 两 个 云 环境 都 连接 到 同一 个 Jenkins 服 务 器 上 。 


代码 清单 10-46 多云 Nodepool 配 置 


labels: 
- name: ubuntu-trusty 
image: ubuntu-trusty 
ready-script: configure mirror.sh 
min-ready: 10 g 
providers: 
- name: zte-podl3-RegionOne 
- name: zte-podll-RegionOne 
- name: ubuntu-trusty-large 
image: ubuntu-trusty-large 
ready-script: configure mirror.sh 
min-ready: 6 
providers: 
- name: zte-podl3-RegionOne 
- name: zte-podll-RegionOne 


providers: 
- name: zte-podl3-RegionOne 
region-name: 'RegionOne' 
cloud: zte-pod13 
http: //www.hzcourse.com/resource/readBook?path-/openresources/teach ebook/uncompressed/17933/OEBPS/Text/... 
images: 
- name: ubuntu-trusty 
min-ram: 2048 
diskimage: ubuntu-trusty 
http: //www.hzcourse.com/resource/readBook?path-/openresources/teach ebook/uncompressed/17933/OEBPS/Text/... 
- name: ubuntu-trusty-large 
min-ram: 8192 
diskimage: ubuntu-trusty 
http: //www.hzcourse.com/resource/readBook?path-/openresources/teach ebook/uncompressed/17933/OEBPS/Text/... 
- name: zte-podll-RegionOne 
region-name: 'RegionOne' 
cloud: zte-podll 
http: //www.hzcourse.com/resource/readBook?path-/openresources/teach ebook/uncompressed/17933/OEBPS/Text/... 
images: 
- name: ubuntu-trusty 
min-ram: 2048 
diskimage: ubuntu-trusty 
http: //www.hzcourse.com/resource/readBook?path-/openresources/teach ebook/uncompressed/17933/OEBPS/Text/... 
- name: ubuntu-trusty-large 
min-ram: 8192 
diskimage: ubuntu-trusty-large 
http: //www.hzcourse.com/resource/readBook?path-/openresources/teach ebook/uncompressed/17933/OEBPS/Text/... 


T 


T 


T 


T 


I 


I 


targets: 
- name: jenkins1 
assign-via-gearman: True 
hostname: jenkinsl-(label.namej]-(provider.name]-(node id) 


代码 清单 10-47 是 代码 清单 10-46 所 示 的 两 个 云 环境 对 应 的 云 连接 参数 配置 。 


代码 清单 10-47 多云 环境 连接 配置 


clouds: 
zte-podll: 
profile: internap 
floating ip source: 'neutron' 
auth: 
username: 'ciuser' 
password: 'ciuser' 
project name: 'ciuser' 
auth url: 'http://openstack-1ll.cibook.oz:5000/v2.0' 
regions: 
- name: RegionOne 
values: 
networks: 
- name: admin floating net 
routes externally: true 
- name: net-ci 
nat destination: true 
default interface: true 


zte-pod13: 
profile: internap 
floating ip source: 'neutron' 
auth: 
username: 'ciuser' 
password: 'ciuser' 
project name: 'ciuser' 
auth url: 'http://openstack-13.cibook.oz:5000/v2.0' 
regions: 
- name: RegionOne 
values: 
networks: 
- name: admin floating net 
routes externally: true 
- name: net-ci 
nat destination: true 
default interface: true 


®© jenkins1-ubuntu-trusty-large-zte-pod11- 
RegionOne-250905 

1 Idle 

2 Idle 


Œ jenkins1-ubuntu-trusty-large-zte-pod11- 
RegionOne-250917 

1 Idle 

2 Idle 


© ienkins1-ubuntu-trus 
RegionOne-250922 


1 Idle 

2 Idle 
jenkins1-ubuntu-trusty-large-zte-pod13- 
HegionOne-243509 

1 ldle 

2 Idle 
Œ jenkins1-ubuntu-trusty-large-zte-pod13- 
RegionOne-243514 

1 Idle 

2 Idle 


& ienkins1-ubuntu-trusty-large-zte-pod13- 
RegionOne-250638 

1 Idle 

2 Idle 
& jenkins1-ubuntu-trusty-zte-pod11- 
RegionOne-250902 

1 Idle 
®© jenkins1-ubuntu-trusty-zte-pod11- 
RegionOne-250904 

1 Idle 
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以 上 各 项 配置 的 具体 含义 参见 第 6 章 中 的 描述 。 


图 10-27 


多 Jenkins 


里 给 出 的 两 个 云 环境 中 ， 用 户 和 租户 都 是 ciuser。 连 接 两 个 云 环 境 后 ，Jenkins 上 注册 的 部 分 VM 如 图 10-26 所 示 。 


需要 说 明 的 是 对 于 多 Nodepool 服 务 的 场景 ， 为 了 避免 各 Nodepool 管 理 的 VM 或 镜像 相互 影响 ， 建 议 在 云 环境 中 为 不 同 的 Nodepool 配 置 不 同 的 租户 ， 


Ms 


这 


对 于 注册 到 Jenkins1 上 的 VM， 根 据 代码 清单 10-46 中 配置 的 VM 命名 规则 hostname:jenkins1-{label.name}-{pro-vider.name}-{node id}， 其 名 称 中 的 pod11 和 pod13 表 明了 VM 所 处 的 云 环 境 为 zte- 
pod11-RegionOne 和 zte-pod13-RegionOne。 


5. 多 Jenkins 


在 当前 的 OpenStack CMVCD 中 ，Jenkins 在 整个 系统 中 处 于 中 心地 位 ， 它 一 定 程度 上 决定 着 整个 系统 的 性 能 。 社 区 的 测试 结果 显示 ， 当 Slave 到 达 一 定 的 数目 (大约 100 左 右 ) 时 ，jJenkins 的 性 能 会 急剧 
下 降 ， 进 而 成 为 整个 系统 的 性 能 瓶颈 。 一 个 解决 方式 就 是 提高 Jenkins 所 在 服务 器 的 性 能 ， 但 这 个 提升 有 限 ， 成 本 一 般 也 较 大 ， 而 且 不 符合 云 化 的 思想 ; 另 一 个 就 是 采用 多 Jenkins 的 方式 ， 借 助 于 Gearman 
的 任务 分 发 机 制 ， 同 时 提供 多 个 Jenkins 服 务 ， 每 个 Jenkins 关 于 Job 的 配置 相同 ， 如 图 10-27 所 示 。 


多 Jenkins 涉 及 的 配置 有 以 下 几 个 方面 : 


首先 ， 增 加 一 个 Jenkins 的 节点 如 jenkins2.0z， 需 要 在 master site.pp 文 件 中 添加 类 似 代码 清单 10-48 所 示 的 信息 。 


代码 清单 10-48 增加 jenkins2 节 点 的 配置 


node 'jenkins2.oz' { 


$vhost name = hiera('vhost name jenkins2', $::fqdn) 


class ( '::openstackci::jenkins node': 
vhost name T 
project config repo => hiera('project config repo'), 


namej"), 


serveradmin 


H WU- U- U- U- U- I- 


jb git 
jb git 


LL o 


t url 


=> S$vhost name, 


=> hiera('serveradmin', "webmaster@$ {vhost | 


enkins version => hiera('jenkins version', 'present'), 
enkins vhost name => hiera('jenkins vhost name2', 'jenkins2'), 
enkins username => hiera('jenkins username2', 'jenkins'), 
enkins password => hiera('jenkins password2', 'XXX'), 
enkins ssh private key => hiera('jenkins ssh private key'), 
enkins ssh public key => hiera('jenkins ssh public key'), 

Og Server 
git revision => hiera('jjb git revision', '1.6.2!), 


=> hiera('log server'), 


=> hiera('jjb git url','https://git.openstack.org/openstack-iní 


fra/jenkins-job-builder'), 


java args override => hiera('java args override', '-Dhudson.model., 
ParametersAction.keepUndefinedParameters-true -Dorg.apache.commons.jelly.tags.fmt.timeZone-Asia/Shanghai!') 


} 
} 


node 'nodepool.oz' { 
4 If the fqdn is not resolvable, use its ip address 
$vhost name = hiera('vhost name nodepool', $::fqdn) 


class ( '::openstackci::nodepool node': 
vhost name => $vhost name, 
project config repo => hiera('project config repo'), 
jenkins username => hiera('jenkins username', 'jenkinsl') 
jenkins username? => hiera('jenkins username', 'jenkins2' 
jenkins ssh public key => hiera('jenkins ssh public key') 
jenkins ssh private key => hiera('jenkins ssh private key') 
oscc file contents => hiera('oscc file contents', ''), 
mysql host => hiera('mysql host'), 
mysql root password => hiera('mysql root password'), 
mysql nodepool password => hiera ('mysql nodepool password'), 
nodepool jenkins target 

=> hiera('nodepool jenkins target', 'jenkins1l'), 


, 
); 
, 
, 


jenkins api key => hiera('jenkins api key', 'XXX'), 
jenkins api key2 => hiera('jenkins api key', 'XXX'), 

jenkins credentials id => hiera('jenkins credentials id', 'XXX'), 
jenkins credentials id2 -» hiera('jenkins credentials id2', 'XXX'), 
jenkins url => hiera('jenkins url', 'http://localhost:8080'), 
jenkins url2 => hiera('jenkins url2', 'http://localhost:8080'), 
nodepool revision => hiera('nodepool revision', 'master'), 


nodepool git source repo 
=> hiera('nodepool git source repo','http://opnfv.zte.com.cn/gerrit/openstack/nodepool'), 


代码 清单 10-48 描 述 的 信息 增加 了 一 个 节点 jenkins2.oz， 并 针对 jenkins2 增 加 了 一 套 参数 jenkins vhost name2, jenkins url2, jenkins api _key2 和 jenkins credentials id2， 其 他 参数 可 以 复 用 既 有 
的 Jenkins 的 配置 。 同 时 需要 修改 已 有 nodepool.oz 节 点 ， 使 其 能 够 连接 jenkins2.oz (openstackci:nodepool node 需要 做 同样 的 修改 ) 。 


. 接着 ， 在 mastet 的 common.yaml 中 增加 新 Jenkins2 的 连接 参数 ， 如 代码 清单 10-49 所 示 。 


代码 清单 10-49 master 增 加 一 套 Jenkins 参 数 配 置 


jenkins vhost name2: jenkins2.oz 

jenkins url2: http://jenkins2:8080 

jenkins api key2: efllcfaebab8659d7f8a3e7cb0649a6e 

jenkins credentials id2: 0f779e44-33f4-4266-8964-d729ab16c15a 


Sm, 

Gur 

jenkins_api_key2 和 jenkins_credentials_id2 的 配置 需要 手动 进行 ， 有 具体 参见 10.2.2 节 中 的 描述 。 
. 最 后 ， 修 改 nodepool.yaml 中 的 配置 ， 代 码 清单 10-50 所 示 。 


代码 清单 10-50 ”多 Jenkins 的 Nodepoo| 配 置 


http: //www.hzcourse.com/resource/readBook?path-/openresources/teach ebook/uncompressed/17933/OEBPS/Text/... 
targets: 
- name: jenkins1 
assign-via-gearman: True 
hostname: jenkinsl-(label.namej]-(provider.name]-(node id) 
- name: jenkins2 
assign-via-gearman: True 
hostname: jenkins2-(label.name]-(provider.name]-(node id] 
http: //www.hzcourse.com/resource/readBook?path-/openresources/teach ebook/uncompressed/17933/OEBPS/Text/... 


jenkins2 对 应 的 连接 参数 ，Puppet Agent 同 步 后 会 自动 生成 到 /etc/nodepool/secure.conf 文 件 中 ， 如 代码 清单 10-51 所 示 。 


代码 清单 10-51 Nodepool 中 Jenkins 连 接 参 数 


http: //www.hzcourse.com/resource/readBook?path-/openresources/teach ebook/uncompressed/17933/OEBPS/Text/... 
[Jenkins "jenkins1"] 

user-jenkins 

apikey-fdllcfaebab8659g7f8a3e7cb0649a6d 

credentials-0e779e44-ebp45-42066-864c-d729ab16c15a 

url-http://jenkins.oz:8080 


[jenkins "jenkins2"] 
user-jenkins 
apikey-efllcfaebab8659d7f8a3e7cb0649a6e 
credentials-0f779e44-33f4-4266-8964-8729ab16c15a 
url-http://jenkins2.0z:8080 


6. 多 Gerrit 

对 于 大 多 数 企 业 来 说 ， 多 Gerrit 的 需求 比较 常见 ， 原 因 也 各 不 相同 : 
1) 异地 开发 ， 基 于 运 维 原 因 都 在 本 地 部 署 一 个 Gerrit。 

2) 出 于 对 安全 的 考量 ， 将 对 内 对 外 的 Gerrit 服 务 分 离 。 

3) 基于 组 织 结构 ， 不 同 的 项 目 或 产品 都 自己 独立 的 Gerrit 系 统 。 


以 上 情况 为 了 充分 利用 资源 或 者 为 集中 统一 管理 ， 可 能 需要 公用 CIMCD 的 其 他 子 系统 ， 如 公用 Jenkins 和 Nodepool。 当 前 版 本 Zuul 还 不 支持 多 Gerrit 接 入 (Zuul V3 会 引入 这 个 新 特性 ) ， 所 以 对 于 多 
Gerrit， 当 前 的 推荐 方案 是 多 Zuul， 即 一 个 Gerrit 对 接 一 个 Zuul， 如 图 10-28 所 示 。 


图 10-28 多 Gerrit 


多 Gerrit 配 置 需要 增加 一 个 Zuul 节 点 ， 如 果 Gerrit 不 是 现 有 的 也 需要 增加 ， 两 者 的 配置 基本 上 是 现 有 Gerrit 和 Zuu| 配 置 的 复制 并 做 简单 修改 ， 在 此 不 再 详细 描述 。 


10.5 “CIMCD 还 需要 考虑 的 问题 


多 节点 部 署 不 仅 解 决 了 Openstack CIMCD 组 件 间 耦 合 的 问题 ， 更 为 整个 CIMCD 系 统 性 能 的 提升 以 及 水 平 扩展 提供 了 可 能 。 对 于 企业 级 的 CMCD， 高 可 用 性 (High Available, HA) 也 必 不 可 少 ， 否 则 一 
个 组 件 服 务 宕 机 会 导致 整个 CI/CD 系 统 都 没 法 工作 。 有 了 前 文 多 节点 方案 以 及 扩展 性 和 性 能 的 讨论 ， 基 于 OpenStack CIMCD 的 HA 的 方案 也 呼之欲出 了 ， 如 图 10-29 所 示 是 作者 提出 的 HA 方案 ， 待 实践 验 


证 。 
Gerrit | 
Zuul Master Gearman m 
Jenkins(A) 

. Zuul Slave Server(A) | V 

Gerrit 2 
OpenStack 

Zuul Master Gearman A /N 

Gerrit 3 dre Jenkins(A) Ta 


Zuul Slave 
OpenStack 


图 10-29 ”基于 OpenStack CI/CD 的 HA 


由 图 10-29 可 知 ，Gearman、Jenkins 和 Nodepool 都 使 用 了 Active-Active 方 式 ， 并 且 每 类 组 件 都 分 别提 供 了 两 个 服务 节点 ， 这 样 某 类 组 件 如 果 其 中 一 个 节点 因为 异常 不 能 正常 工作 ， 其 服务 可 以 由 另 一 


个 节点 接 蔡 。Zuul 相 对 比较 特殊 ， 只 能 使 用 Active/Standby (tblllMaster/Slave) 方式 ， 即 Master 处 于 Active 状 态 ，Slave 处 于 Standby 状 态 ，Master 和 Slave 保 持 状态 同步 。 当 Master 出 现 异常 或 升级 时 
Slave 会 成 为 Master， 从 而 保持 Zuul 服 务 的 连续 性 ; 对 于 连接 不 同 Gerrit 的 Zuul， 分 别提 供 Master/Slave 对 ， 不 同 Zuul Master/Slave 对 之 间 彼 此 独立 。 


图 10-29 中 接 入 了 两 个 OpenStack 环 境 提 供 Slave 节 点 ， 每 个 OpenStack 同 时 接收 两 个 Node-pool 管 理 ， 为 避免 VM 浪费 ， 每 个 OpenStack 提 供 一 半 的 Slave。 


mék 


需要 特别 说 明 的 是 ， 对 于 Gerrit， 只 能 
比较 独立 ， 可 以 根据 需要 部 署 多 个 ， 且 每 个 LogServer 独 立 配置 ， 在 此 也 不 做 详细 介绍 。 


接 入 一 个 Zuul， 连 接 多 个 Zuul 门 控 系 统 可 能 会 带 来 运行 结果 的 冲突 。 此 外 ，ELK 的 HA 都 可 以 独立 形成 集群 ， 已 有 解决 方案 ， 故 不 在 讨论 范围 之 内 ; LogServer 也 


除了 HA 之 外 ， 企 业 级 的 CIMCD 还 需要 对 接 企业 的 认证 系统 ， 尤 其 是 Gerrit， 但 这 不 在 本 文 的 讨论 范围 之 内 ， 有 兴趣 的 读者 可 以 参考 Gerrit 官 方 文档 。 


10.6 本章 小 结 


本 章 首先 简单 介绍 了 Puppet 的 相关 概念 ; 然后 依据 社区 的 指导 文档 实践 了 OpenStack CI/CD 的 单机 部 署 ， 对 相关 配置 做 了 较为 详细 的 讲解 ， 接 着 为 了 满足 生产 环境 部 署 的 需要 ， 给 出 了 多 节点 的 部 署 


方案 和 相关 配置 指导 ， 并 站 在 项 目 管理 者 、 普 通 开发 者 和 基础 设施 维护 者 的 角度 ， 概 要 阐述 了 如 何在 CMCD 系 统 中 增加 新 项 目 、 贡 献 代码 以 及 系统 的 维护 ; 最 后 讨论 了 在 使 用 该 系统 框架 时 企业 还 需要 考虑 
的 典型 问题 ， 以 及 推荐 方案 。 通 过 本 章 的 学 习 ， 和 希望 读者 能 搭建 一 个 满足 企业 内 部 需要 的 CIMCD 环 境 。 


随 着 OpenStack 社 区 项 目 持续 增加 、 技 术 不 断 演进 和 发 展 ， 对 基础 设施 也 提出 了 更 多 的 需求 和 挑战 。 为 了 使 基础 设施 更 简单 、 灵 活 ， 易 于 使 用 和 扩展 ，CI/CD 技 术 也 在 不 断 往 前 演进 和 发 展 。 


本 章 重点 介绍 V2 版 本 CI/CD 系 统 中 存在 的 问题 及 针对 这 些 问 题 社区 做 的 技术 演进 和 未 来 的 发 展 方向 。 


11.1 存在 的 问题 


首先 ，Zuul 的 项 目 配 置 不 分 租户 ， 所 有 信息 共享 不 利于 管理 和 维护 ， 同 时 Job 的 配置 仓库 和 项 目 仓 库 分 离 ， 不 利于 测试 ; 其 次 ，CI/CD 中 实际 使 用 到 的 Jenkins 功 能 比较 少 ， 并 且 /JB 需 要 适 配 Jenkins 的 
版 本 演进 ; 最 后 ，Nodepool 对 于 支持 多 节点 测试 比较 低 效 ， 而 且 当 前 只 支持 虚 机 方式 的 资源 池 已 经 不 能 满足 部 分 场景 测试 需求 。 


11.1.1 384 


Zuul V2 版 本 中 ， 所 有 项 目的 Job 配 置 在 公共 的 openstack-infra/project-conf ig 仓 库 中 ， 项 目 代 码 本 身 有 自己 的 仓库 ， 建 立 一 个 项 目的 CI 需要 分 两 步 进行 : 
| 在 公共 仓库 的 jenkins/jobs 中 定义 Job， 并 在 该 库 的 zuul/layout.yaml 文 件 中 增加 对 应 pipeline 下 该 Job 的 引用 。 
. 项 目 中 持续 集成 直到 Job 运 行 正常 。 


这 种 模式 的 缺点 是 ， 通 常情 况 下 开发 人 员 在 不 同 项 目的 权限 不 同 ， 项 目 开发 人 员 在 公共 仓库 中 提交 本 项 目的 Job 定 义 ， 需 要 公共 项 目 库 的 核心 开发 人 员 批 准 才能 合 入 ， 合 入 之 后 才能 在 项 目 库 中 调试 ， 非 
常 不 便于 项 目 人 员 修 改 和 测试 Job; 同时 公共 项 目 库 的 开发 人 员 其 实 应 该 不 关心 项 目 具体 Job 的 实现 ， 这 种 模式 增加 了 不 同 项 目 开 发 人 员 的 工作 量 。 


11.1.2 Zuul 


Zuul V2 只 支持 对 接 一 个 Gerrit， 没 有 租户 的 概念 ， 所 有 的 项 目 配置 都 存储 在 同一 个 文件 layout.yaml 中 。 而 随 着 需求 的 演进 ， 支 持 对 接 多 个 Gerrit 服 务 器 或 者 其 他 代码 管理 系统 很 有 必要 。 这 种 场景 下 如 
果 所 有 的 配置 存储 在 一 个 文件 中 则 不 易于 管理 和 维护 。 而 且 对 于 具有 相似 行为 的 一 组 项 目 可 能 并 不 关心 其 他 不 相关 项 目的 配置 信息 ， 同 时 由 于 不 同 代码 管理 系统 的 触发 条 件 不 同 ，pipeline 的 配置 有 可 能 冲 
突 。 因 此 在 该 应 用 场景 下 需要 支持 对 项 目 分 租户 ， 在 同一 租户 下 共享 相同 的 配置 信息 ， 租 户 可 以 自行 定义 需要 管理 哪些 项 目 。 比 如 所 有 OpenStack 相 关 被 管理 的 项 目 放 在 openstack 租 户 下 。 


e. 
iR 


这 里 租户 的 概念 和 OpenStack 云 环境 中 的 租户 概念 不 一 样 ， 指 共享 Zuul 配 置 的 一 组 项 目的 集合 。 


11.1.3 Jenkins 


Openstack CI/CD 使 用 的 Jenkins 功 能 很 少 ，JB 的 定义 也 比较 复杂 ， 其 中 一 些 复杂 性 来 自 需要 支持 特定 的 Jenkins 行 为 ， 由 于 Jenkins 的 版 本 更 新 ，JJB 可 能 需要 重新 适 配 。 


11.1.4 Nodepool 


1. 多 节点 测试 低 效 
虽然 V2 版 本 已 经 做 了 扩展 ， 采 用 特定 标签 的 方式 支持 单个 任务 多 节点 测试 ， 但 过 程 非常 低 效 : 
` 需要 同时 创建 该 标签 下 的 所 有 节点 ， 可 能 会 导致 创建 节点 延迟 ; 


: 不 能 随 着 使 用 而 扩展 ， 因 为 它们 仅 适用 于 该 标签 下 的 多 节点 任务 ， 该 标签 下 提供 的 节点 数量 在 运行 过 程 中 不 能 增 减 ， 不 能 用 于 其 他 多 节点 任务 ， 因 此 节点 大 部 分 时 间 可 能 处 于 空闲 状态 ， 造 成 资源 浪 
费 。 比 如 有 两 个 多 节点 任务 A 和 B ，A 任 务 运行 在 A (3 个 节点 ) 标签 上 ，B 任 务 运 行 在 B (5 个 节点 ) 标签 上 ， 当 前 有 B 标 签 的 资源 池 空 闲 ， 当 需要 构建 A 任 务 时 ， 空 闲 的 5 个 节点 可 以 满足 3 个 节点 测试 需求 ， 但 


是 由 于 A 任务 指定 了 A 节点 标签 而 无 法 调度 到 B 节 点 标签 上 运行 ， 这 就 造成 了 资源 的 浪费 。 


H 


2. 单 类 型 的 动态 Slave 节 点 


随 着 测试 需求 的 增多 ， 有 些 测试 场景 需要 运行 在 裸 机 或 者 容器 上 ，Nodepoo| 单 一 的 动态 虚 机 节点 管理 已 经 不 能 满足 测试 需求 ， 需 要 增加 对 裸 机 和 容器 的 支持 。 


11.2.1 架构 


针对 上 述 存在 的 问题 和 需求 ， 社 区 基础 架构 团队 在 V2 版 本 上 进行 了 大 量变 更 和 改进 ， 移 除了 Jenkins 组 件 ， 增 强 了 Nodepool 功 能 ， 并 重 写 了 Zuul， 即 Zuul V3。 


系统 架构 如 图 11-1 所 示 ， 可 以 看 出 整体 框架 改动 不 少 。 
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图 11-1 ZuulV3 系 统 架 构 


Zuul V3 有 四 个 组 件 服 务 ， 内 部 通过 Gearman 通 信 ， 分 别 完 成 如 下 功能 : 
: zuul-scheduler: 主 处 理 服务 ， 和 V2 版 本 的 zuul-setvet 服 务 功 能 大 致 相同 ， 负 责 接收 外 部 事件 、 驱 动 执 行 Job、 收 集 和 上 报 结果 ， 以 及 协调 其 他 服务 的 工作 。 
: zuul-merger: 执行 一 系列 git 操 作 ， 和 V2 没有 区 别 ; 新 增 可 弹性 伸缩 配置 ， 可 选 0 或 者 多 个 。 
zuul-executor: 新 增 服务 ， 执 行 Job 的 服务 ， 和 zuul-merger 一 样 可 弹性 伸缩 ， 至 少 配 置 1 个 服务 ， 如 果 没 有 配置 zuul-merger， 由 Zuul-executor 完 成 zuul-merget 的 功能 。 
: zuul-web: 新 增 Web 服 务 ， 提 供 RESTful API. 
移 除了 Jenkins，Zuul 通 过 Zookeeper 与 Nodepool 交 互 请 求 节点 信息 。 
Nodepool V3 有 两 个 组 件 服务 ， 内 部 通过 Zookeeper 通 信 ， 分 别 完 成 如 下 功能 。 
- nodepool-launcher: 和 V2 版 本 的 Nodepool 服 务 相同 ， 管 理 云 虚 机 ， 区 别 在 于 虚 机 信息 由 原来 存储 在 数据 库 中 改 为 存储 在 Zookeeper 中 。 
: nodepool-builder: 构建 和 上 传 镜像 到 云 环境 ， 和 V2 版 本 无 差别 。 


整体 工作 流 如 图 11-2 所 示 ， 上 有 具体 分 析 如 下 : 
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图 11-2 V3 工作 流程 


1) 贡献 者 在 代码 管理 系统 上 操作 : 比如 在 Gerrit 上 提交 新 patch， 添 加 评论 或 者 合 入 patch 等 ; 

2) Gerrit 产 生 一 个 通知 事件 到 它 的 事件 流 中 (event stream) ; 

3) zuul-scheduler 从 事件 流 中 读 取 事 件 ， 匹 配 事件 到 一 个 或 多 个 pipeline， 找 到 该 patch 对 应 的 项 目下 的 pipeline 任 务 ， 依 次 完成 如 下 操作 : 
. 通过 Gearman 向 zuul-metget 提 交代 码 合 并 任务 ; 

- 通过 Zookeeper 向 nodepool-launcher 请 求 任务 节点 ; 

. 通过 Gearman 向 zuul-exectutor 提 交 执 行 Job。 

4) zuul-merger 完 成 代码 合并 ; 

5) nodepool-launcher 根 据 节 点 请 求 信息 分 配 相应 的 节点 并 返回 节点 信息 ; 

6) zuul-executor 根 据 任务 信息 动态 加 载 任务 定义 ， 并 生成 Ansible Playbook， 使 用 Ansible 在 对 应 的 节点 上 运行 测试 ; 


7) zuul-executor 通 过 Gearman 返 回 测试 结果 到 zuul-scheduler:; 


8) 根据 测试 结果 ，zuul-scheduler 在 Gerrit 中 对 patch 添 加 一 个 review 结 果 。 


整体 工作 流 和 V2 版 本 的 主要 差别 在 于 任务 的 加 载 、 节 点 的 请 求 和 分 配 以 及 任务 的 执行 方式 。 下 面 介 绍 下 每 个 组 件 支持 的 新 特性 。 


11.2.1 架构 


针对 上 述 存在 的 问题 和 需求 ， 社 区 基础 架构 团队 在 V2 版 本 上 进行 了 大 量变 更 和 改进 ， 移 除了 Jenkins 组 件 ， 增 强 了 Nodepool 功 能 ， 并 重 写 了 Zuul， 即 Zuul V3, 


系统 架构 如 图 11-1 所 示 ， 可 以 看 出 整体 框架 改动 不 少 。 
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图 11-1 Zuul V3 系统 架构 
Zuul V3 有 四 个 组 件 服务 ， 内 部 通过 Gearman 通 信 ， 分 别 完成 如 下 功能 : 
: zuul-scheduler: 主 处 理 服务 ， 和 V2 版 本 的 zuul-setvet 服 务 功 能 大 致 相同 ， 负 责 接收 外 部 事件 、 驱 动 执 行 Job、 收 集 和 上 报 结果 ， 以 及 协调 其 他 服务 的 工作 。 
 zuul-merger: 执行 一 系列 git 操 作 ， 和 V2 没有 区 别 ; 新 增 可 弹性 伸缩 配置 ， 可 选 0 或 者 多 个 。 
. zuul-executor: 新 增 服务 ， 执 行 Job 的 服务 ， 和 zuul-merget 一 样 可 弹性 伸缩 ， 至 少 配 置 1 个 服务 ， 如 果 没 有 配置 zuul-merger， 由 zuul-executor 完 成 zuul-metget 的 功能 。 
- zuul-web: 新 增 Web 服 务 ， 提 供 RESTful API, 
移 除了 Jenkins，Zuul 通 过 Zookeeper 与 Nodepool 交 互 请 求 节点 信息 。 
Nodepool V3 有 两 个 组 件 服务 ， 内 部 通过 Zookeeper 通 信 ， 分 别 完 成 如 下 功能 。 
- nodepool-launcher: 和 V2 版 本 的 Nodepool 服 务 相同 ， 管 理 云 虚 机 ， 区 别 在 于 虚 机 信息 由 原来 存储 在 数据 库 中 改 为 存储 在 Zookeeper 中 。 
: nodepool-builder: 构建 和 上 传 镜像 到 云 环境 ， 和 V2 版 本 无 差别 。 


整体 工作 流 如 图 11-2 所 示 ， 具 体 分 析 如 下 : 


].Patch zuul-mergers 


2.event streams 
8.review m 
.git merge 
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图 11-2 V3 工作 流程 


1) 贡献 者 在 代码 管理 系统 上 操作 : 比如 在 Gerrit 上 提交 新 patch， 添 加 评论 或 者 合 入 patch 等 ; 

2) Gerrit 产 生 一 个 通知 事件 到 它 的 事件 流 中 (event stream) ; 

3) zuul-scheduler 从 事件 流 中 读 取 事 件 ， 匹 配 事件 到 一 个 或 多 个 pipeline， 找 到 该 patch 对 应 的 项 目下 的 pipeline 任 务 ， 依 次 完成 如 下 操作 : 
. 通过 Gearman 向 zuul-metget 提 交代 码 合 并 任务 ; 

- 通过 Zookeeper 向 nodepool-launcher 请 求 任务 节点 ; 

. 通过 Gearman 向 zuul-exectutor 提 交 执 行 Job。 

4) zuul-merger 完 成 代码 合并 ; 

5) nodepool-launcher 根 据 节 点 请 求 信息 分 配 相应 的 节点 并 返回 节点 信息 ; 

6) zuul-executor 根 据 任务 信息 动态 加 载 任务 定义 ， 并 生成 Ansible Playbook， 使 用 Ansible 在 对 应 的 节点 上 运行 测试 ; 


7) zuul-executor 通 过 Gearman 返 回 测试 结果 到 zuul-scheduler:; 


8) 根据 测试 结果 ，zuul-scheduler 在 Gerrit 中 对 patch 添 加 一 个 review 结 果 。 


整体 工作 流 和 V2 版 本 的 主要 差别 在 于 任务 的 加 载 、 节 点 的 请 求 和 分 配 以 及 任务 的 执行 方式 。 下 面 介 绍 下 每 个 组 件 支持 的 新 特性 。 


11.2.2 Zuul V3 


1. 分 布 式 配置 


Zuul V3 版 本 中 ， 项 目的 Job 配 置 分 布 在 各 个 项 目的 仓库 中 ， 在 变更 合并 前 测试 ， 简 化 了 测试 工作 流程 。openstack-infra/zuul-jobs 是 默认 Job 配 置 库 ， 包 含 常用 Job 定 义 ，Zuul 仅 需 导 入 本 地 配置 中 尚 
未 定义 的 Job。 这 对 于 第 三 方 Cl 来 说 是 个 好 消息 ， 因 为 V2 版 本 中 需要 在 第 三 方 CI 系统 的 Jenkins 上 配置 所 有 Job， 而 新 框架 下 只 需 配置 第 三 方 Job， 重 用 上 游 的 公共 Job， 如 tox-docs 或 tox-py35 等 。 


2. 多 租户 配置 
项 目 按 租 户 配 置 划分 ， 同 一 个 租户 下 共享 相同 的 配置 信息 。 
3. 多 代码 管理 系统 的 集成 
V2 版 本 只 支持 和 单个 Gerrit 集 成 ， 新 版 本 不 仅 支 持 多 Gerrit 对 接 ， 而 且 集 成 多 代码 管理 系统 ， 比 如 github， 更 加 灵活 可 扩展 。 
4.Ansible Job 定 义 
使 用 Ansible 作 为 运行 CI 测试 的 基础 ，Job 在 Ansible 中 创建 具有 如 下 优势 : 
-多 节点 架构 ，Job 易 于 分 发 ; 
: Ansible 模 块 生态 系统 简化 了 复杂 的 Job，; 
- Playbook 可 以 手动 执行 ; 
- 更 容易 获得 构建 日 志 。 
5.Zuu| 新 增 服务 


新 增 zuul-executor 服 务 执行 原来 由 Jenkins 完 成 的 Job 加 载 和 执行 的 功能 ;新 增 zuul-web 服 务 提 供 RESTful AP1， 包 括 租户 信息 和 状态 查询 ， 指 定 租户 下 的 变更 、Job 和 构建 查询 等 。 


11.2.3 Nodepool V3 


1. 显 式 节点 操作 


支持 显 式 的 节点 创建 和 删除 。 对 于 多 节点 测试 ， 此 模型 效率 更 高 ， 不 再 需要 特殊 的 多 节点 标签 。 按 照 不 同 Job 配 置 来 请 求 可 用 节点 资源 池 。 如 果 当 前 可 用 的 节点 配置 和 数目 满足 要 求 ， 则 分 配 节 点 做 测 
试 ; 不 满足 则 按照 配置 信息 创建 新 的 所 需 节 点 。 这 种 模型 下 节点 的 需求 和 分 配 计算 更 简单 。 


2. 支 持 更 多 类 型 的 资源 池 


原来 支持 基于 OpenStack 创 建 的 动态 节点 资源 池 不 变 ， 增 加 一 个 基于 驱动 程序 的 设计 来 支持 非 OpenStack 的 Provider， 该 接口 通用 ， 可 用 于 实现 新 的 Provider， 比 如 容器 或 静态 节点 等 ， 目 前 已 经 支持 
静态 节点 的 驱动 [1]。 


[1] https://review.openstack.org/#/c/535553/。 


113 CI/CD 友 展 


V3 版 本 虽然 在 V2 上 做 了 很 多 改进 ， 但 是 在 大 规模 的 迁移 和 使 用 过 程 中 ， 仍 然 暴露 出 一 些 问 题 和 需求 。 
1. 无 服务 中 断 


当前 如 果 用 户 修改 Zuul 的 配置 ， 需 要 重启 服务 才能 生效 ， 如 果 用 户 频 繁 更 新 配置 ， 必 然 引 起 服务 中 断 。 无 服务 中 断 是 Zuul 下 一 个 版 本 主要 解决 的 问题 ， 通 过 扩展 Zuul 的 scheduler 服 务 来 避免 宕 机 和 频 
繁 更 新 。 


2. 任 务 在 指定 租户 下 运行 
对 于 多 租户 的 云 环 境 ， 特 定 租 户 下 的 节点 类 型 只 能 由 特定 租户 使 用 ， 对 于 这 种 应 用 场景 ， 如 何在 Job 中 指定 租户 下 的 节点 ， 也 是 社区 当前 热门 的 讨论 话题 。 
3. 支 持 容器 /Baremetal 作 为 Slave 节 点 


随 着 容器 技术 的 成 熟 ，Nodepool 支 持 容器 的 slave 节 点 也 是 大 势 所 趋 ， 这 一 功能 正在 开发 中 。 而 Baremetal 的 支持 由 于 应 用 场景 比较 复杂 ， 比 如 静态 节点 也 可 以 是 Baremetal， 或 者 通过 
openstack+ironic、ironic+bifrost、cabbler、maas 等 驱动 方式 ， 社 区 正在 考虑 先 文档 化 这 些 驱动 方式 配置 ， 再 由 用 户 按 照 需求 实现 对 应 的 驱动 即 可 。 


11.4 本章 小 结 


本 章 主要 介绍 了 Zuul V3 版 本 的 新 特性 以 及 未 来 的 技术 演进 方向 ( 即 Zuul V4) ， 感 兴趣 的 读者 可 以 直接 参与 到 社区 中 讨论 和 贡献 。 


